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-  'r  Certain  features  of  programming  languages,  such  as  data  structure  opera¬ 
tions  and  procedure  call  mechanisms,  have  been  found  to  resist  formalization  by 
classical  techniques.  An  alternate  approach  is  presented,  based  on  a  “situational 
calculus,”  which  makes  explicit  reference  to  the  states  of  a  computation.  For  each 
state,  a  distinction  is;  drawn  between  an  expression,  its  value,  and  the  location  of 
the  value.. 

Within  this  conceptual  framework,  the  features  of  a  programming  language  j 
can  be  described  axiomatically.  Programs  in  the  language  can  then  be  synthesized, 
executed,  verified,  or  transformed  by  performing  deductions  in  this  axiomatic 
system.  Properties  of  entire  classes  of  programs,  and  of  programming  languages, 
can  also  be  expressed  and  proved  in  this  way.  The  approach  is  amenable  to 
machine  implementation. 

In  a  situational-calculus  formalism  it  is  possible  to  model  precisely  many  ! 
"problematic”  features  of  programming  languages,  including  operations  on  such 
data  structures  as  arrays,  pointers,  lists,  and  records,  and  such  procedure  call 
mechanisms  as  call-by-reference,  call-by-value,  and  call-by-name.  No  particular 
obstacle  is  presented  by  aliasing  between  variables,  by  declarations,  or  by  recursive 
procedures. 

I 

The  paper  is  divided  into  three  parts,  focusing  respectively  on  the  assignment 
statement,  on  data  structure  operations,  and  on  procedure  call  mechanisms.^ In_ 
this  first  part,  we  introduce  the  conceptual  framework  to  be  applied  throughout 
and  present  the  axiomatic  definition  of  the  assignment  statement.  If  suitable 
restrictions  on  the  programming  language  are  imposed,  the  well-known  Hoare 
assignment  axiom  can  then  be  proved  as  a  theorem.  However,  our  definition  can 
also  describe  the  assignment  statement  of  unrestricted  programming  languages, 
for  which  the  Hoare  axiom  does  not  hold. 
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ABSTRACT 


Certain  features  of  programming  languages,  such  as  data  structure  opera¬ 
tions  and  procedure  call  mechanisms,  have  been  found  to  resist  formalisation  by 
classical  techniques.  An  alternate  approach  is  presented,  based  on  a  "situational 
calculus,”  which  makes  explicit  reference  to  the  states  of  a  computation.  For  each 
state,  a  distinction  is.  drawn  between  an  expression,  its  value,  and  the  location  of 
the  value. 

Within  this  conceptual  framework,  the  features  of  a  programming  language 
can  be  described  axiomatically.  Programs  in  the  language  can  then  be  synthesised, 
executed,  verified,  or  transformed  by  performing  deductions  in  this  axiomatic 
system.  Properties  of  entire  classes  of  programs,  and  of  programming  languages, 
can  also  be  expressed  and  proved  in  this  way.  The  approach  is  amenable  to 
machine  implementation. 

In  a  situational-calculus  formalism  it  is  possible  to  model  precisely  many 
"problematic”  features  of  programming  languages,  including  operations  on  such 
data  structures  as  arrays,  pointers,  lists,  and  records,  and  such  procedure  call 
mechanisms  as  call-by-reference,  call-by-value,  and  call-by-name.  No  particular 
obstacle  is  presented  by  aliasing  between  variables,  by  declarations,  or  by  recursive 
procedures. 

The  paper  is  divided  into  three  parts,  focusing  respectively  on  the  assignment 
statement,  on  data  structure  operations,  and  on  procedure  call  mechanisms.  In 
this  first  part,  we  introduce  the  conceptual  framework  to  be  applied  throughout 
and  present  the  axiomatic  definition  of  the  assignment  statement.  If  suitable 
restrictions  on  the  programming  language  are  imposed,  the  well-known  Hoare 
assignment  axiom  can  then  be  proved  as  a  theorem.  However,  our  definition  can 
also  describe  the  assignment  statement  of  unrestricted  programming  languages, 
for  which  the  Hoare  axiom  does  not  hold. 
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1.  INTRODUCTION 


The  most  widely  accepted  approach  to  program  verification  has  been  the  one 
described  in  Floyd’s  [1967]  paper  and  formalized  by  Hoare  [1969].  Hoare’s  for* 
malization  requires  that  each  construct  of  the  programming  language  be  described 
by  an  axiom  or  rule,  specifying  how  the  construct  alters  the  truth  of  an  arbitrary 
assertion.  Certain  features  of  programming  languages  have  been  found  to  be  easier 
to  describe  in  this  way  than  others: 

•  Programs  with  only  simple  assignment  statements  and  while  statements  can 
be  described  adequately. 

•  Programs  with  arrays  are  less  tractable,  but  can  be  treated  if  the  array  opera¬ 
tions  are  rewritten  in  terms  of  of  McCarthy’s  [1962]  assign  and  contents  func¬ 
tions. 

•  Operations  on  other  data  structures,  such  as  pointers,  lists,  and  records,  can  be 
handled  only  if  special  restrictions  are  imposed  on  the  language. 

•  Different  varieties  of  procedure  calls  have  also  required  programming-language 
restrictions. 

•  Even  the  simple  assignment  statement  fails  to  satisfy  the  usual  Hoare  assignment 
axiom  if  included  in  a  programming  language  with  other  problematic  features. 

•  Certain  combinations  of  features  have  been  shown  (Clarke  [1977])  to  be  impos¬ 
sible  to  describe  at  all  with  a  Hoare-style  axiomatization. 

It  has  been  argued  (e.g.,  in  London,  R.  L.  et  al.  [1978])  that  features  of 
programming  languages  whose  semantics  are  difficult  to  describe  with  the  Floyd- 
Hoare  technique  are  also  difficult  for  people  to  understand  and  use  consistently. 
For  this  reason,  a  number  of  programming  languages  have  been  designed  with 
the  intention  of  eliminating  or  restricting  such  “problematic”  features.  Others 
have  objected  (e.g.,  Knuth  [1974],  Hoare  [1975],  deMillo  et  al.  [1979])  that  the 
disciplined  use  of  such  “unverifiable”  programming  features  can  facilitate  the  clear 
and  direct  representation  of  a  desired  algorithm,  while  their  removal  may  force 
the  programmer  into  increasingly  obscure  circumlocutions. 

In  this  paper,  we  present  a  conceptual  framework  capable  of  describing  all 
these  problematic  programming  features.  This  framework  is  suitable  to  serve  as 
a  basis  for  the  implementation  of  verification  systems,  as  well  as  synthesis  and 
transformation  systems.  We  do  not  argue  that  the  problematic  features  should 
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necessarily  be  included  in  programming  languages  without  restriction,  but  we 
intend  that  if  a  language  designer  wishes  to  use  some  combination  of  features,  no 
obstacle  should  be  imposed  by  verification  concerns. 

The  approach  we  employ  is  a  ‘situational  calculus,”  in  which  we  refer  ex¬ 
plicitly  to  the  states  of  the  computation.  In  a  given  state  t,  the  evaluation  of  an 
expression  e  of  the  programming  language  produces  a  new  state  s; «.  The  meaning 
of  the  expression  can  then  be  defined  by  axioms  that  relate  the  characteristics  of 
the  new  state  to  those  of  the  original  state. 

This  formalism  is  quite  distinct  from  that  of  Hoare,  in  which  no  explicit 
reference  is  made  to  states.  In  this  respect,  our  approach  is  closer  to  those  adopted 
by  McCarthy  [1964]  and  Burstall  [1969]  for  specifying  the  semantics  of  ALGOL-60 
subsets,  and  by  Green  [1969]  for  describing  robot  operations. 

To  describe  the  characteristics  of  the  states  of  a  computation,  we  introduce 
‘situational  operators,”  i.e.,  functions  and  predicates  whose  values  depend  on  the 
state.  In  defining  these  operators,  we  distinguish  between  the  expressions  of  the 
programming  language,  the  storage  locations  of  the  machine,  and  the  abstract 
data  objects  of  the  program’s  domain.  The  precision  of  this  descriptive  apparatus 
enables  us  to  model  the  effects  of  programming-language  constructs  in  full  detail. 
We  can  describe  and  compare  various  implementations  of  the  same  programming 
language  or,  if  we  prefer,  we  can  ignore  the  details  of  implementation. 

Once  we  have  succeeded  in  describing  the  constructs  of  a  programming  lan¬ 
guage,  we  can  use  that  description  in  proving  that  programs  in  the  language 
satisfy  a  given  specification.  The  situational  operators  can  be  used  not  only  to 
describe  the  constructs  of  the  language  but  also  to  represent  the  specifications  of  a 
program.  Indeed,  they  are  more  expressive  for  this  purpose  than  the  conventional 
input/output  assertions,  because  they  enable  us  to  refer  in  a  single  sentence  to 
different  states  of  the  computation.  For  example,  it  is  possible  to  say  directly 
how  the  final  value  of  an  identifier  relates  to  its  initial  or  intermediate  values.  To 
show  that  a  program  satisfies  such  a  specification,  we  then  prove  a  corresponding 
theorem  in  situational  calculus. 

The  situational-calculus  approach  can  be  applied  not  only  to  prove  that  a 
single  program  satisfies  given  properties,  but  also  to  prove  that  an  entire  class  of 
programs,  or  a  programming  language,  satisfies  given  properties.  For  example,  we 
can  state  and  prove  that  the  ‘aliasing”  phenomenon,  in  which  two  identifiers  are 
different  names  for  the  same  location,  cannot  be  created  in  languages  that  satisfy 
certain  constraints. 
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Although  the  approach  has  been  devised  to  treat  languages  for  which  the 
Hoare  formalism  breaks  down,  it  can  also  be  used  to  show  that  the  Hoare  for¬ 
malism  does  actually  apply  to  suitably  restricted  programming  languages.  For 
example,  we  can  show  that  the  Hoare  assignment  axiom  (which  fails  to  apply  to 
most  languages  used  in  practice)  is  true  and  can  be  proved  as  a  situational-calculus 
theorem  for  languages  in  which  the  problematic  features  have  been  omitted. 

Up  to  now,  we  have  been  discussing  the  use  of  a  situational-calculus  approach 
for  proving  properties  of  given  programs  and  classes  of  programs.  Historically, 
however,  we  were  led  to  this  approach  in  developing  a  method  for  program  syn¬ 
thesis,  i.e.,  the  systematic  construction  of  a  program  to  meet  given  specifications. 
We  have  described  elsewhere  (Manna  and  Waldinger  (1980])  a  deductive  technique 
for  the  synthesis  of  applicative  programs,  t'.e.,  programs  that  yield  an  output  but 
produce  no  side  effects.  We  can  now  construct  programs  that  may  produce  side 
effects  by  applying  the  same  deductive  technique  within  the  situational  calculus. 
More  precisely,  to  construct  a  program  to  achieve  a  desired  condition,  we  prove 
the  existence  of  a  state  in  which  the  condition  is  true.  The  proof  is  constrained 
to  be  "constructive,”  so  that  a  program  to  achieve  the  desired  condition  can  then 
be  extracted  from  the  proof. 

The  same  deductive  technique  can  be  applied  to  the  task  of  transforming 
a  given  program,  generally  to  improve  its  efficiency.  Often  the  performance  of  a 
program  can  be  augmented,  at  the  expense  of  clarity,  by  applying  transformations 
that  introduce  side  effects.  This  transformation  process  can  be  conducted  within 
a  situational-calculus  deductive  system  to  ensure  that  the  original  purpose  of 
the  given  program  is  preserved.  For  example,  a  purely  applicative  program  for 
reversing  a  list  can  be  transformed  into  one  that  achieves  the  same  purpose  with 
side  effects,  by  altering  the  structure  of  the  list. 

The  situational  calculus  is  a  more  appropriate  logic  of  programs  than  dynamic 
logic  (Pratt  [1976]),  because  it  is  able  to  describe  the  results  of  evaluating  nested 
expressions  as  well  as  the  effects  of  executing  sequences  of  statements:  dynamic 
logic  is  not  intended  to  apply  to  expression-oriented  languages.  The  approach  of 
this  paper  is  more  similar  in  intent  and  scope  to  that  of  denotational  semantics, 
but  ours  relies  on  a  simpler  mathematical  framework.  We  do  not  use  functions 
of  higher  type,  lambda  expressions,  or  fixed  points.  Situational  calculus  can  be 
embedded  comfortably  in  a  first-order  logic  to  which  the  well-developed  battery 
of  mechanical  theorem-proving  techniques,  such  as  the  unification  algorithm,  can 
be  applied.  In  particular,  no  special  difficulty  is  presented  by  the  existential 
quantifier,  which  is  outside  the  scope  of  denotational  semantics-based  systems 
(e.p.,  Gordon  et  al.  [1979]),  but  which  is  valuable  for  program  verification  and 
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crucial  for  program  synthesis. 

The  paper  is  divided  into  three  parts.  The  present  part  (Part  I)  introduces 
the  general  conceptual  framework  and  discusses  its  application  to  the  assign¬ 
ment  statement.  Future  parts  describe  the  application  of  the  same  conceptual 
framework  to  the  description  of  data  structure  operations  and  procedure  call 
mechanisms. 

We  begin  (in  Motivation)  by  describing  some  of  the  features  of  programming 
languages  that  have  caused  problems  in  the  past,  and  indicate  sources  of  the 
difficulty.  We  then  introduce  (in  Conceptual  Framework)  the  situational  operators 
that  define  the  characteristics  of  states.  The  conceptual  framework  is  then  used 
(in  The  Assignment  Statement)  to  express  the  axioms  that  describe  the  behavior 
of  the  simple  assignment  statement.  We  show  (in  Hoare’s  Assignment  Aziom)  that 
the  statement  usually  taken  as  the  assignment  axiom  can  be  expressed  and,  for 
suitably  restricted  programming  languages,  proved  as  a  theorem  in  our  formalism. 
Finally  (in  Assignment  Expressions),  we  apply  the  conceptual  framework  to  a 
wider  class  of  programs,  which  violate  the  Hoare  axiom. 

In  the  forthcoming  Part  II,  we  apply  the  technique  to  describe  data  structures 
and  the  operations  that  manipulate  them.  We  introduce  a  general  notion  of  data 
structure,  which  includes  arrays,  pointers,  trees,  and  records,  and  we  define  an 
operation  for  altering  such  a  data  structure.  A  single  set  of  axioms  describes  the 
behavior  of  this  operation.  We  allow  different  data  structures  to  share  substruc¬ 
tures,  and  we  do  not  exclude  circular  structures. 

In  the  forthcoming  Part  III,  we  use  our  situational-calculus  framework  to 
describe  declarations  and  procedure  calls.  We  consider  several  different  calling 
mechanisms,  including  call-by-reference,  call-by-value,  and  call-by-name,  and  we 
admit  both  static  and  dynamic  binding  of  global  identifiers.  We  allow  procedures 
to  be  passed  as  arguments  to  other  procedures.  No  special  problems  are  presented 
by  recursive  calls. 

We  will  not  be  concerned  in  this  paper  with  the  problems  presented  by 
computer  arithmetic,  array  bounds,  types,  coercion,  or  error  recovery,  although 
these  can  be  described  in  our  formalism  with  no  special  difficulty.  We  will 
also  ignore  the  phenomena  of  parallelism  and  nondeterminism;  these  require 
substantive  extension  of  the  framework. 
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In  this  section,  we  discuss  some  features  of  programming  languages  that  have 
proved  difficult  to  formalize  in  the  classical  framework,  and  we  outline  some  of 
the  solutions  that  have  been  proposed.  In  the  following  section  we  introduce  a 
general  framework  that  uniformly  resolves  all  these  difficulties. 

We  begin  with  one  of  the  less  problematic  features  —  the  simple  assignment 
statement 


A.  Assignment  to  Identifiers 

By  the  simple  assignment  statement  we  mean  one  of  the  form 
x«-t, 

where  x  is  an  identifier  and  t  is  an  expression  in  the  programming  language.  The 
Hoare  axiom  for  such  an  assignment  may  be  expressed  as 


{Po(x-t)}x-t{/>}, 

indicating  that  if  the  assertion  P  <(x*~  t)  holds  before  executing  the  assignment 
x  «•  t,  and  if  the  execution  terminates,  then  the  assertion  P  holds  afterward. 
Here,  Fo(x  «-  t)  is  the  result  of  replacing  all  free  occurences  of  x  in  P  by  t. 
The  rationale  for  this  rule  is  that  the  value  of  x  after  executing  the  assignment 
x  *■  t  will  be  the  same  as  the  value  of  t  before;  therefore,  anything  that  can  be 
said  about  t  before  the  execution  can  be  said  about  x  afterwards. 

However,  the  above  reasi  T  is  faulty,  and  only  applies  if  certain  restrictions 
are  applied  to  the  expression  t,  the  assertion  P,  and  the  situation  in  which  the 
assignment  takes  place.  Let  us  examine  some  of  these  restrictions: 

•  The  expression  t  must  be  static,  in  the  sense  that  its  evaluation  must  not  itself 
produce  side  effects.  For  example,  in  the  assignment 

x  «*  (  x  ♦  (y  y+1)  ), 

the  evaluation  of  t,  that  is,  x+(y «-  y+1),  has  the  side  effect  of  altering  the  value 
of  the  identifier  y.  Such  assignments  are  legal  in  the  ALGOL  dialects  and  in 
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LISP.  If  we  take  the  assertion  P  to  be  y  =  0,  then  according  to  the  Hoare  axiom, 
we  have 


{y  =  0}  x  ♦  (  x+(y  «■  y+1)  )  {y  =  0}. 

(Note  that  the  assertion  (y  =  0)  o  (x  «—  t)  reduces  to  y  =  0  because  x  does  not 
occur  in  y  =  0.)  However,  this  sentence  is  false  because,  if  y  is  0  before  executing 
this  assignment,  then  afterwards  y  will  be  1,  not  0. 

Similarly,  the  assignment 

x  «•  f(x), 

where  f  is  a  procedure  that  has  the  side  effect  of  increasing  the  value  of  the  global 
identifier  y  by  1,  violates  the  instance  of  the  Hoare  axiom 

{y  =  0}  x  -  f(x)  {y  =  0}. 


•  In  the  situation  in  which  the  assignment  to  the  identifier  x  takes  place,  there 
must  be  no  way  to  refer  to  x  indirectly,  in  terms  of  other  identifiers.  For  example, 
suppose  x  and  y  are  “aliases,”  t.e.,  they  are  different  names  for  the  same  location. 
Then  changing  the  value  of  x  wilt  also  change  the  value  of  y.  If  P  is  the  condition 
(y  =  0},  then  the  instance  of  the  Hoare  axiom 

{y  =  0}  x  «*  1  {y  =  0} 

is  false  because,  after  executing  the  assignment,  the  value  of  y  will  be  1,  not  0. 

In  practice,  the  aliasing  phenomenon  can  arise  in  languages  that  admit  pro¬ 
cedure  calls.  For  example,  suppose  we  have  a  procedure 

f(x,  y)  <=  x  -  i 

whose  parameters  are  passed  by  a  call-by-reference  mechanism.  In  other  words, 
in  executing  a  procedure  call  f(u,  v),  where  u  and  v  are  identifiers,  the  identifiers 
x  and  u  become  aliases,  and  the  identifiers  y  and  v  become  aliases.  In  executing 
the  procedure  call  f(u4,-  u),  all  three  identifiers  x,  y,  and  u  become  aliases,  so 
altering  the  value  of  x  will  alter  the  value  of  y  as  well.  Thus,  the  assignment 
statement  x  «■  1  tMht  occurs  in  the  body  of  the  procedure  f(x,  y)  will  violate  the 
instance  of  the  Hoare  axiom 

(y*=  0)  x  «•  1  {y  =  0). 

* 
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Aliasing  can  occur  in  other  ways  besides  the  action  of  the  procedure  call 
mechanism.  In  FORTRAN  an  alias  can  be  created  directly  by  the  action  of  the 
“common”  or  “equivalence"  statements. 

Other  situations,  aside  from  simple  aliasing,  in  which  the  Hoare  axiom  is 
violated  occur  when  the  identifier  x  is  bound  to  a  substructure  of  some  data 
structure.  Then  altering  the  value  of  x  will  indirectly  alter  the  value  of  the 
structure. 

•  The  assertion  P  may  not  refer  to  the  value  of  an  identifier  except  by  mentioning 
the  identifier  explicitly.  For  example,  suppose  P  is  the  assertion 

“there  exists  an  identifier  whose  value  is  2.” 

Because  P  contains  no  occurrences  of  x  at  all,  the  sentence 

{F>  x  «-  0  {P} 

is  an  instance  of  the  Hoare  axiom.  However,  if  x  is  the  only  identifier  whose  value 
is  2  before  executing  the  assignment,  then  P  will  become  false  afterwards.  Here, 
the  axiom  broke  down  because  P  referred  to  the  value  of  x  without  mentioning 
x  itself. 

Many  of  the  problems  connected  with  the  assignment  statement,  and  a  denota- 
tional  approach  to  their  solution,  are  described  in  Ligler  (1975). 


B.  Array  Assignments 

The  direct  translation  of  the  Hoare  assignment  axiom  to  array  assignments 
is 

{P  **  (a[x3  <—  t)}  a[x]  «■  t  {P}. 

This  sentence  is  false,  even  for  straightforward  expressions  t  and  assertions  P, 
and  for  the  simplest  situations.  For  example,  the  sentence 

My]  =  0}  a[x]  «■  1  {a[y]  =  0} 


is  an  instance  of  the  above  sentence,  because  a[xj  does  not  occur  at  all  in  the 
assertion  a[y]  =  0;  but  of  course  the  sentence  is  false  if  x  and  y  have  the  same 
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values.  The  problem  is  that,  while  it  is  exceptional  for  two  identifiers  x  and  y  to 
be  aliases,  it  is  commonplace  for  two  array  entries  a[x]  and  a[y]  to  be  alternative 
names  for  the  same  location. 

The  difficulty  has  been  approached  (McCarthy  [1962])  by  regarding  the  entire 
array  as  a  single  entity,  so  that  assigning  to  any  of  the  array's  entries  produces  a 
new  array.  More  precisely,  we  regard  the  entire  array  a  as  an  ordinary  identifier, 
we  treat  an  array  assignment  a[x]  «■  t  as  an  abbreviation  for  a  simple  assignment 

a  *  assign(a,  x,  t), 

and  we  treat  an  array  access  a[y]  as  an  abbreviation  for 
contents(a,  y). 

The  assign  and  contents  functions  are  then  assumed  to  satisfy  the  properties 
contents(assign(a,  x,  t).  y)  =  t  if  x  =  y 


and 


contents(assign(a,  x,  t),  y)  =  contents(a,  y)  if  x  ^  y. 

Programs  involving  arrays  can  then  be  treated  by  the  Hoare  axiom  for  simple 
identifier  assignments. 

Thus,  the  previous  false  sentence 

{a[y]  =  0}  a[x]  «■  t  {a[y]  =  0}, 

expressed  in  terms  of  the  contents  and  assign  functions,  is 

{contents(a,  y)  =  0}  a  «■  assign(a,  x,  t)  {contents(a,  y)  =  0). 

This  sentence  is  not  an  instance  of  the  Hoare  assignment  axiom,  because  the 
assertion  contents(a,  y)  =  0  does  contain  an  occurrence  of  the  identifier  a.  The 
appropriate  instance  of  the  Hoare  axiom  in  this  case  is  the  true  sentence 


{(contents(a,  y)  =  0)  <o(*  ♦-  assign(a,  x,  t))} 
a  «■  assign(a,  x,  t) 

{contents(a,  y)  —  0), 
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t.e. 


{contents(assign(a,  x,  t),  y)  =  0} 
a  *•  assign(a,  x,  t) 

{contents(a,  y)  =  0). 


Although  this  solution  still  suffers  from  the  limitations  associated  with  the 
simple  assignment  axiom,  it  resolves  the  special  difficulties  arising  from  the  intro¬ 
duction  of  arrays. 


C.  Pointer  Assignment 


To  describe  the  pointer  mechanism,  let  us  introduce  some  terminology.  If  an 
identifier  is  declared  in  a  program,  there  is  some  location  bound  to  that  identifier; 
we  can  regard  the  location  as  a  cell  in  the  machine  memory.  If  two  identifiers 
are  aliases,  they  are  bound  to  the  same  location.  A  location  may  contain  data  or 
it  may  store  (the  address  of)  another  location;  we  thus  distinguish  between  data 
locations  and  storage  locations.  A  pointer  is  a  storage  location  that  stores  (the 
address  of)  another  storage  location.  There  are  many  notations  for  pointers  in 
different  programming  languages;  ours  is  typical  but  is  not  actually  identical  to 
any  of  these. 

A  pointer  is  created,  for  example,  by  the  execution  of  the  simple  assignment 


x-  ty, 


where  x  and  y  are  both  identifiers.  Here  the  notation  ty  means  the  location 
bound  to  the  identifier  y.  The  result  of  this  assignment  is  that  the  location  bound 
to  y  is  stored  in  the  location  bound  to  x.  The  configuration  produced  may  be 
represented  by  the  following  diagram: 
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Figure  2.1 


Here,  o  and  P  are  locations  bound  to  x  and  y,  respectively;  71  is  the  location 
stored  in  p. 

If  we  subsequently  execute  a  simple  assignment  statement 
y*t, 

where  t  is  an  expression,  we  alter  the  contents  of  the  location  p  that  y  is  bound 
to.  The  location  P  will  then  store  the  location  72  yielded  by  the  evaluation  of  t. 
The  new  configuration  can  be  represented  by  the  following  diagram: 


Figure  2.2 


We  have  remarked  that  such  a  configuration  can  easily  lead  to  violations  of  the 
Hoare  assignment  axiom:  a  simple  assignment  to  y  can  alter  the  truth  of  an 
assertion  about  x. 
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Suppose  instead  we  execute  the  special  pointer  assignment 
ix  «■  t. 

The  notation  ix  means  that  the  location  altered  by  the  assignment  is  not  the 
location  a  bound  to  x,  but  rather  the  location  P  stored  in  a.  In  other  words,  the 
effect  of  the  above  pointer  assignment  is  identical  to  that  of  the  simple  assignment 
y  + t,  and  results  in  the  same  configuration  depicted  above. 

A  naive  extension  of  the  Hoare  axiom  to  pointer  assignments  is 
{P«(lx  «*  t)}  ix«-t{P>. 


The  sentence 


{y  =  0}  ix  «•  1  {y  =  0} 

is  an  instance  of  this  axiom,  because  ix  does  not  occur  in  the  assertion  y  =  0. 
However,  as  we  have  seen,  if  x  “points  to”  y  the  assignment  ix  *•  1  can  set  the 
value  of  y  to  1 .  In  short,  the  simple  adaptation  of  the  Hoare  assignment  axiom 
fails  to  describe  the  action  of  the  pointer  assignment,  because  the  assignment  can 
alter  the  value  of  an  identifier  not  mentioned  explicitly. 

The  assign/contents  technique  for  arrays  has  been  extended  [e.g.,  see  Cart¬ 
wright  and  Oppen  (1978])  to  pointers  by  regarding  all  the  identifiers  in  the  program 
as  entries  in  a  single  array  v,  which  is  indexed  not  by  integers,  but  by  identifiers. 
These  array  operations  can  then  be  treated  as  simple  assignments  in  terms  of  the 
assign  and  contents  functions,  and  are  correctly  described  by  the  Hoare  simple 
assignment  axiom  and  the  two  McCarthy  axioms  for  assign  and  contents- 

The  Hoare  formalism  itself  was  extended  by  Schwarts  and  Berry  [1979]  to 
handle  pointers  and  other  constructs  of  ALGOL  68.  This  approach  employs  two 
distinct  mechanisms  to  refer  to  the  states  of  a  computation:  the  Hoare  P{F}Q 
operator  and  explicit  situational  operators. 


D.  Tree  and  Record  Structure  Manipulation 

The  problems  involved  with  arrays  and  pointers  are  compounded  in  lan¬ 
guages  with  facilities  for  manipulating  more  complex  structures,  such  as  trees 


■'S 
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and  records.  Up  to  now  we  have  considered  only  locations  that  contain  data  or 
that  store  (the  address  of)  a  single  other  location.  To  treat  general  data  struc¬ 
tures,  we  introduce  locations  that  can  store  (the  address  of)  arbitrarily  many  other 
locations. 

For  example,  in  LISP  we  admit  binary-tree  locations,  which  can  store  precisely 
two  locations.  If  a  is  a  binary-tree  location,  we  will  call  the  two  locations  stored  in 
a  the  left  and  right  descendants  of  a.  Of  course,  these  locations  may  themselves  be 
binary-tree  locations.  We  will  refer  to  the  descendants  of  a  as  a  set  that  includes 
not  only  a’s  left  and  right  descendants,  but  also  their  left  and  right  descendents, 
and  so  on;  we  will  say  that  a  is  one  of  their  ancestors. 

We  will  depict  a  binary-tree  location  a  and  its  left  and  right  descendents  ol 
and  a  a  by  the  following  diagram: 


Figure  2.3 


We  do  not  exclude  the  possibility  that  a  binary-tree  location  is  identical  to 
any  of  its  own  descendants;  such  a  configuration  is  called  a  circular  tree.  For 
example,  the  tree  below  is  circular: 


Figure  2.4 
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LISP  provides  two  functions,  which  we  will  call  left  and  right,  for  accessing 
the  corresponding  descendants  of  a  binary-tree  location.  Suppose  t  is  an  expression 
whose  evaluation  yields  a  binary-tree  location  a;  in  other  words,  a  represents  the 
value  of  t.  Then  the  evaluation  of  left(t)  and  right(t)  yields  the  left  and  right 
descendants  of  a,  respectively. 

LISP  also  provides  two  operations  for  altering  binary  trees:  the  rplaea  opera¬ 
tion  ,  which  we  denote  by 


left(e)  «•  t, 


and  the  rplacd  operation,  which  we  denote  by 


right(e)  «■  t, 


where  e  and  t  are  any  expressions.  If  the  evaluation  of  e  yields  a  binary-tree 
location  a,  and  if  the  evaluation  of  t  then  yields  a  location  fi,  then  the  rplaea 
operation  left(e)  *■  t  will  cause  p  to  become  the  new  left  descendant  of  a.  The 
rplacd  operation  behaves  analogously. 


The  problem  in  describing  the  rplaea  and  rplacd  operations  is  precisely  the 
same  as  for  the  pointer  assignment:  a  rplaea  operation  on  one  binary  tree  can  alter 
the  value  of  another  without  mentioning  it  explicitly.  For  example,  suppose  that 
x  and  y  are  identifiers  associated  with  binary-tree  locations  a  and  ft,  respectively, 
in  the  following  configuration: 


If  we  execute  the  rplaea  operation  left(y)  «•  t,  we  obtain  the  configuration 
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Figure  2.6 


where  6  is  the  location  yielded  by  the  evaluation  of  t.  Note  that  the  subsequent 
evaluation  of  the  expression  left(left(x))  yields  the  location  6,  not  the  location 
7i .  In  other  words,  the  value  of  x  may  have  been  changed  by  the  rplaca  operation, 
even  though  the  operation  was  applied  to  y,  not  to  x.  Similarly,  if  a  had  any 
other  ancestors  before  the  execution  of  the  rplaca,  then  their  values  could  also 
have  been  affected  by  the  operation.  It  seems  that,  to  model  the  effects  of  such  an 
assignment  completely,  we  must  know  all  of  the  ancestors  of  the  altered  location. 

Many  languages  admit  a  more  general  form  of  tree  structure  called  a  record, 
in  which  a  record  location  can  store  several  other  locations.  Binary  trees  can  then 
be  regarded  as  a  special  type  of  record.  The  same  problems  that  arise  with  trees 
clearly  come  up  with  records  as  well. 

The  assign/contents  formalization  of  arrays  has  been  extended  to  apply 
to  tree  and  record  structures  by  Wegbreit  and  Poupon  (1972],  Cartwright  and 
Oppen  [1978],  Levy  [1978],  and  Kowaltowski  [1979].  Burstall  [1972]  represents 
the  operations  that  alter  tree  and  record  structures  by  introducing  new  functions 
to  access  the  structures.  For  example,  an  rplaca  operation  is  said  to  create  a  new 
access  function  left',  which  behaves  like  the  left  function  after  the  execution  of 
the  assignment. 


E.  Expressiveness  of  Specifications 

Many  of  the  difficulties  that  prevent  us  from  describing  the  behavior  of 
individual  programming  constructs  with  the  Floyd/Hoare  approach  also  impede 
our  efforts  to  express  the  specifications  that  describe  the  desired  behavior  of  entire 


MOTIVATION  17 


programs.  The  only  mechanism  for  forming  specifications  in  that  approach  is  a 
pair  of  input  and  output  assertions.  We  have  already  encountered  one  weakness 
in  the  expressive  power  of  such  assertions:  there  is  no  way  to  refer  to  an  identifier 
without  mentioning  it  explicitly.  For  example,  we  were  unable  to  deal  with  an 
assertion  such  as 

“there  exists  an  identifier  whose  value  is  2" 
in  which  we  refer  to  an  identifier  indirectly. 

Other  such  limitations  also  restrict  our  ability  to  specify  programs.  For 
example,  suppose  we  wish  to  state  that  a  given  procedure  will  behave  properly  if 
initially  two  of  its  input  parameters  x  and  y  are  not  aliases  of  each  other,  s‘.e., 
they  are  not  bound  to  the  same  location. 

A  natural  approach  might  be  to  introduce  the  condition 
nof(a/tos(x,  y)) 

as  part  of  the  program’s  input  assertions  and  to  describe  the  relation  oItas(x,  y) 
with  axioms  or  rules  of  inference.  However,  this  relation  cannot  be  expressed  in 
an  assertion,  because  x  and  y  are  meant  to  refer  to  locations,  not  values.  Thus, 
the  relation  will  violate  even  the  simple  assignment  axioms;  e.g.,  the  instance  of 
the  Hoare  axiom 

{a/tas(x,  y)}  z «-  y  {a/tas(x,  z)} 

is  false:  if  x  and  y  are  aliases,  then  assigning  the  value  of  y  to  z  will  not  cause 
x  and  z  to  become  aliases. 

This  shortcoming  foils  a  plausible  approach  to  retaining  the  Hoare  formalism: 
forbidding  aliasing  to  occur  in  situations  where  it  can  lead  to  trouble.  We  certainly 
can  forbid  such  occurrences,  but  we  cannot  express  the  condition  we  want  to 
forbid  as  a  Hoare  assertion. 

Another  awkward  aspect  of  in  the  FIoyd/Hoare  assertion  mechanism  as  a 
specification  device  is  its  inability  to  refer  to  more  than  one  state  in  a  single 
assertion.  Thus,  it  is  impossible  in  an  output  assertion  to  refer  directly  to  the 
initial  or  intermediate  value  of  an  identifier.  For  example,  suppose  we  want  to 
say  that  a  program  reverses  the  values  of  two  identifiers  x  and  y.  The  traditional 
approach  is  to  introduce  a  "ghost”  input  assertion 


{x  =  x0  and  y  =  y0> 
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at  the  beginning  of  the  program,  so  that  at  the  end  we  can  assert  that 
{x  =  y0  and  y  =  x0}. 

The  purpose  of  the  input  assertion  is  merely  to  give  names  to  the  initial  yalues 
of  x  and  y.  We  must  be  careful,  of  course,  to  ensure  that  xo  and  y0  are  new 
identifiers  that  do  not  occur  in  the  program. 

The  flaw  in  this  solution  is  apparent  if  we  attempt  to  use  the  above  program 
not  in  isolation  but  as  a  segment  of  a  larger  program  or  as  the  body  of  a  procedure. 
In  this  case,  we  would  normally  have  to  prove  that  the  initial  assertion 

{x  =  x0  and  y  =  y0} 

is  true  when  control  enters  the  segment;  but  this  is  impossible,  because  so  and  po 
are  new  symbols  that  cannot  occur  earlier  in  the  program.  Special  mechanisms 
are  required  for  dealing  with  ghost  assertions. 


F.  Procedures 

We  have  already  seen  that  procedure  calls  can  cause  aliasing  to  occur,  which 
obstructs  attempts  to  axiomatize  the  assignment  statement;  we  have  also  seen  how 
global  side  effects  of  procedure  calls  foil  the  assignment  statement  axiom atization. 
Many  other  problems  arise  in  describing  the  procedure  call  mechanism  itself. 
Let  us  consider  only  one  of  these  difficulties:  expressing  how  global  identifiers 
of  procedures  are  treated  in  languages  with  static  binding. 

A  global  identifier  of  a  procedure  is  one  that  occurs  in  the  procedure’s  body 
but  is  not  one  of  its  parameters.  For  example,  consider  the  procedure  f(x)  declared 
by 


f(x)  *=  x  «■  x  +  y. 

Here,  y  is  a  global  identifier  of  f,  but  x  is  not. 

In  a  language  with  static  binding,  such  as  PASCAL  or  the  ALGOL  dialects, 
the  binding  of  y  that  would  be  used  in  evaluating  the  procedure  is  the  binding 
that  y  had  when  the  procedure  was  declared.  On  the  other  hand,  in  a  language 
with  dynamic  binding,  such  as  LISP,  the  binding  used  would  be  the  one  that  y 
had  when  the  procedure  was  called. 
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Static  binding  is  difficult  to  treat  bj  a  Hoare  rule  for  a  procedure  call  because 
it  requires  that  we  refer  to  the  binding  the  global  identifier  y  had  in  a  much  earlier 
state,  when  the  procedure  f  was  first  declared.  In  the  meantime,  of  course,  y  may 
have  been  redeclared. 

***** 

It  is  the  intention  of  this  paper  to  present  a  single  conceptual  framework 
capable  of  describing  all  of  these  problematic  programming-language  features. 
This  framework  is  compatible  with  contemporary  theorem-proving  techniques  and 
can  be  incorporated  into  systems  for  the  synthesis,  verification,  and  transforma¬ 
tion  of  computer  programs. 


3.  CONCEPTUAL  FRAMEWORK 


In  this  section  we  introduce  the  conceptual  framework  on  which  our  descrip¬ 
tion  of  programming-language  constructs  is  based. 


A.  The  Objects 

We  assume  that  the  objects  we  consider  include  the  following: 

•  A  set  S  of  states,  including  a  special  undefined  state  J_,. 

•  A  set  PL  of  expressions  in  a  programming  language.  We  will  use  boldface 
(boldface)  symbols  to  denote  expressions  in  PL. 

•  A  set  L  of  (machine)  locations,  including  a  special  undefined  location  J_*.  The 
defined  locations  are  divided  into  three  disjoint  sets: 

o  the  data  locations, 

o  the  storage  locations,  and 

o  the  structure  locations 

•  A  set  D  of  data  objects,  including  the  logical  objects  true  and  false,  and  the 
undefined  object  The  defined  data  objects  include 

o  the  atomic  data  objects  (or  atoms). 

The  intuition  that  motivates  these  definitions  is  as  follows: 

A  data  object  is  an  abstract  mathematical  entity,  such  as  a  number,  a 
function,  or  a  string.  The  atoms  will  be  those  data  objects  that  are  not  considered 
to  be  composed  of  other  data  objects.  Typically,  integers  and  the  truth  values 
true  and  false  will  be  atoms;  lists,  strings,  and  functions  will  be  nonatomic  data 
objects. 

The  data  and  structure  locations  are  the  machine  representations  of  the  data 
objects;  the  data  locations  represent  the  atomic  data  objects;  the  structure  loca¬ 
tions  represent  the  nonatomic  data  objects.  (We  will  not  be  discussing  nonatomic 
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data  objects  and  structure  locations  in  Part  I  of  this  paper.)  A  storage  location 
is  one  that  can  store  (or  point  to)  another  location. 

We  will  not  restrict  ourself  to  any  particular  programming  language,  although 
from  time  to  time  we  will  introduce  typical  language  features  for  discussion.  Our 
intention  is  that  the  formalism  should  be  expressive  enough  to  describe  a  wide 
class  of  programming-language  constructs. 

Let  us  assume  that  the  programming  language  PL  contains  a  class  of  ident¬ 
ifiers.  We  mean  the  identifiers  to  include  those  symbols,  such  as  2,  that  are  used 
as  names  for  atomic  data  objects.  Furthermore,  we  assume  that  a  sequencing 
operation  is  included  in  PL;  thus  if  ej,  e2,  ...,  en  are  expressions,  then 
ei;  e2<  . . . ;  en  is  an  expression  that  denotes  the  program  that  evaluates  first  «i, 
then  e2,  . . . ,  and  finally  en. 

A  state  is  a  particular  situation  in  the  course  of  a  computation.  If  s  is  a  state 
and  e  is  an  expression,  then  a;  e  denotes  the  result  of  evaluating  the  expression  • 
in  state  s.  If  «i,  e2,  . . . ,  and  en  are  several  expressions,  then  s;«it  «at  . . .  i  •» 
denotes  the  state  that  results  if  we  evaluate  ei,e2,  in  sequence,  beginning 

in  state  s.  We  will  assume  the  sequence  property 

<31  >  *;(ci;«2)  =  (s;ei);e2, 

so  that  we  can  write  s;ei;e2  without  ambiguity.  If  the  evaluation  of  •  in  state  s 
leads  to  an  error  or  does  not  terminate,  then  s;  e  will  turn  out  to  be  the  undefined 
state  J_#. 

Furthermore,  if  s  itself  is  undefined,  then  a;e  is  also  undefined,  i.e., 

<3.2>  _L.;e=J_,. 


B.  Basic  Situational  Operators 

Situational  operators  are  functions  or  predicates,  one  of  whose  arguments  is 
a  state.  They  are  used  to  denote  entities  that  may  change  during  a  computation. 
We  will  use  the  following  situational  functions  for  any  state  s: 

•  for  any  identifier  x, 
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is  a  location 

•  for  any  location  l, 

store(s,  t) 

is  also  a  location 

•  for  any  location  l, 

data(s,  t) 

is  a  data  object. 

The  intuition  behind  these  definitions  is  that  if  x  is  an  identifier  bound  to  a 
machine  location  t  ( e.g .,  via  a  symbol  table),  then  Ioe(«,x)  =  t.  If  t\  is  a  location 
that  addresses  (or  stores)  a  location  t 2 ,  then  stort[s,l\)  =  I2.  If  t  is  a  location 
that  represents  a  data  object  d,  then  data{s,  i)  =  d. 

The  situational  functions  may  take  undefined  arguments  and  yield  undefined 
values.  We  assume  that  the  situational  functions  are  strict,  in  the  sense  that  if  any 
of  their  arguments  are  undefined,  then  their  value  is  undefined  too.  For  example, 
if  s  is  the  undefined  state  J_,,  then  loc(s,x)  =J_t .  Furthermore,  if  the  identifier 
x  is  not  declared  in  a  defined  state  3,  then  loc(s,x)  =_L*  as  well.  We  assume 
that  if  t  is  a  data  or  structure  location,  then  8tore(s,£)  =_L<  in  any  state  »;  in 
addition,  store(s,  l)  may  be  undefined  even  if  l  is  a  storage  location  in  a  defined 
state  ». 

We  define  three  situational  predicates.  For  any  state  t  and  location  l- 

•  isdata{s,  t)  is  true  if  l  is  a  data  location  in  state  » 

•  i»store{s,  t)  is  true  if  l  is  a  storage  location  in  state  $ 

•  is  structure^,  l)  is  true  if  l  is  a  structure  location  in  state  s 

Note  that  the  situational  predicates  are  never  undefined;  if  any  of  their  arguments 
are  undefined,  they  are  false. 

The  relationship  among  the  sets  of  data,  storage,  and  structure  locations  can 
now  be  expressed  in  terms  of  these  predicates: 


<3.3>  isdata{*,t)  or  isstore(s,t)  or  isstructure{$,t) 
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<3.4>  not{isdata(s,t )  and  is$tore(s,t)) 

<3.5>  not{isdata(s,t)  and  isstructure(s,l )) 

<3.6>  not(isstore{s,l )  and  isstrueture(s,£)) 

for  all  defined  states  s  and  defined  locations  £. 

We  assume  that  the  store  operator  “transmits”  data;  i.e., 

<  3.7  >  data{s,  t)  =  data{s,  store[s,  £))  if  isstore{»,  (). 

In  other  words,  if  one  location  stores  another,  we  consider  them  to  represent  the 
same  data  object.  For  example,  consider  the  following  configuration: 


Figure  3.1 


y-" 


loc 


loc 


loc 


Here,  because 

storc(s,a)  =  f)  and  store(s,fi)  =  7, 

we  have 

data(s,  a)  =  data(s,  0)  =  data(s,  7)  =  2. 

Thus,  we  can  conclude  that  the  full  diagram  for  this  configuration  would  be 
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The  definition  of  data(s,  l)  for  structure  locations  l  will  be  given  in  the 
forthcoming  Part  II.  Now,  let  us  give  some  examples  to  illustrate  the  use  of  these 
concepts. 


Example  (constant): 

Assume  that  the  programming  language  PL  contains  the  identifier  2;  then 
normally,  this  identifier  would  be  bound  to  a  data  location  that  represents  the 
data  object  2. 

This  configuration  is  illustrated  by  the  following  diagram 


Figure  3.3 


2 


If  terms  of  our  situational  operators,  we  have 

loc(8,Z)  =  a 
data(s,a )  =  2. 


where 


isdata(s,  a)  is  true. 


An  assignment  statement  will  be  defined  (in  a  later  section)  to  alter  the 
store  link  of  a  storage  location.  An  identifier  is  bound  to  a  data  location  rather 
than  a  storage  location  if  we  do  not  intend  to  alter  its  value  by  an  assignment 
statement.  Thus,  numbers  such  as  1, 2.2,  *4,  etc.  and  other  special  identifiers 
such  as  pi  or  nil  might  be  bound  in  this  way.  In  common  parlance,  such  identifiers 
or  their  associated  locations  are  called  "constants”;  however,  we  will  avoid  this 
terminology  because  it  conflicts  with  the  way  the  word  "constant”  is  used  in  logic. 

Example  (variable): 

Assume  that  the  identifier  x  is  bound  to  a  storage  location  at,  that  a  stores 
(addresses)  a  data  location  0,  and  that  0  represents  the  data  object  2.  (We  will 
avoid  using  the  word  "variable,”  commonly  applied  to  x  or  a,  because  of  a  conflict 


CONCEPTUAL  PRAMEWORK  25 


with  logical  usage.) 
following  diagram: 


Figure  3.4 


The  configuration  we  hare  described  is  illustrated  by  the 


“•2 


In  terms  of  our  situational  operators,  we  have 

loc[s,  x)  =  o 
store(s,a)  =  P 
data(s,P)  =  2 


where 


i$store(8,  a)  is  true 
i$data{s,0)  is  true. 

Informally,  we  will  refer  to  a  situational  function  in  a  given  state  as  a  "link*; 
thus,  we  will  say  there  is  a  store  link  between  a  and  p  in  state  i. 


C.  Derived  Situational  Operators 

There  are  some  other  situational  operators  that  are  defined  in  terms  of  the 
basic  situational  operators. 

•  The  situational  function  yield(s,  x)  is  the  location  yielded  by  the  evaluation  of 
an  identifier  x  in  state  s.  We  will  define  it  by 

<3.8>  yield(s,  x)  =  loc{»,  x)  if  tsdata(s,/oc(s,x)) 

or  it8tructure[*,  loe{8,  x)) 

<3.9>  yield(8,x)  —  8tore{s,loc(8,x))  if  t««tore(s,/oc(s,x)) 

for  all  states  s  and  identifiers  x.  In  other  words,  if  x  is  bound  to  a  data  or 
structure  location,  then  the  evaluation  of  x  yields  that  location.  On  the  other 
hand,  if  x  is  bound  to  a  storage  location,  then  the  evaluation  of  x  yields  the 
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location  stored  in  that  storage  location.  Thus,  the  diagrams  that  illustrate  these 
two  situations  are 

__  loc  a _  _  data 

Figure  3.5  * - ^id — 


and 


Figure  3.6 


•  The  situational  function  val(s,  x)  is  the  ralue  of  x  in  state  i.  We  define  it  to 
be  the  data  object  represented  b j  yield(s,x);  i.e., 

<3.10>  val(s,  x)  =  data(s,  yield(t,  x)) 

for  all  states  s  and  identifiers  x.  Depending  on  whether  loc{»,  x)  is  a  data  or 
structure  location  or  a  storage  location,  the  vaJ  operator  is  illustrated  b y  one  of 
the  following  two  diagrams: 


Figure  3.7 


and 


Figure  3.8 


In  the  first  diagram,  a  is  a  data  or  structure  location;  in  the  second,  a  is  a  storage 
location. 
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Note  that  from  the  definitions  of  yield  and  val  and  the  strictness  of  the  basic 
situational  functions,  it  follows  that 

•  if  $  is  the  undefined  state  X«  or  if  loc(t,  x)  is  the  undefined  location  _Lt»  (hen 
yield{t,  x)  is  ±e 

and 

•  if  9  is  _L„  or  if  loc(s,  x)  is  J or  if  yield(s,  x)  is  J_t,  then  val(s,  x)  is  J_d- 

From  the  definitions  of  the  yield  and  data  operators,  we  can  prone  the  fol¬ 
lowing  value  property  of  identifiers: 

<3.1 1  >  val{s,x)  =  data{»,  loc(s,  x)). 

Proof: 

We  distinguish  between  three  cases: 

Case:  isdata{s,loe{$,x))  or  is$tructure(s,loe[s,x)).  Then,  yield{s,x)  is  defined 
to  be  loe(s,  x).  The  property  reduces  to  the  definition  of  val. 

Case:  t sstorefs,  loc(s,  x)).  Then, 


val(s,  x)  =  data{s,  yield(s,  x)) 

by  the  definition  of  val  <3.10> 

=  data(s,  storefs,  loc(s,  x))) 

by  the  definition  of  yield  <3.9> 

=  data(s,  loc(s,  x)) 

by  the  assumed  property  of  data  <3.7> 


Case:  loe(s,x))  =±e.  Then  val(s,x)  =J_<*  and  data(«,Joc(«,x))  =JL*,  by 
the  strictness  of  the  situational  functions.  | 

In  the  future,  we  will  often  ignore  the  undefined  case  if  it  follows  directly 
from  the  strictness  of  the  situational  functions. 
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Example  (pointer): 


Here,  a  and  /?  are  storage  locations  and  7  is  a  data  location.  The  three  identifiers 
x,  y,  and  z  are  bound  to  different  locations,  the  evaluation  of  x  and  y  yields 
different  locations,  but  the  values  of  x,  y,  and  z  are  the  same;  i.e., 

val{$,  x)  =  val(s,  y)  =  val(s,  z)  =  2  | 

In  general,  we  shall  say  that  a  state  t  is  numerically  faithful  if 
val(s,  1)  =  1 
t >al(s,2.2)  =  2.2 
val[s,  -4)  =  —4 

etc,  for  all  numerical  identifiers  in  PL.  In  some  versions  of  FORTRAN  one  can 
construct  defined  states  that  are  not  numerically  faithful.  In  such  a  (pathological) 
state,  the  value  of  the  identifier  2  might  be  the  data  object  1. 


D.  Levels  of  Equality 

In  a  situational-calculus  framework,  we  can  define  four  different  relationships 
between  two  identifiers  x  and  y,  each  of  which  causes  them  to  have  the  same 
value. 
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•  identity. 

Here,  x  and  y  are  identical :  they  stand  for  the  same  identifier;  i.e., 
x  =  y. 

Hence, 

loc(s,x)  =  loc(s,  y), 
yield{$,  x)  =  yield{s,  y),  and 
val(s,x)  =  val{s,  y), 

in  any  state  a. 

•  aliasing-. 

Here,  x  and  y  may  be  syntactically  distinct;  i.e.,  possibly  x^y.  But  x  and 
y  are  aliases  in  the  given  state  s:  they  are  bound  to  the  same  location;  i.e., 

loc(s,x)  =  loc(s,y ) 

and  hence 

yield(s ,  x)  =  yield(s,  y),  and 
val(s,x )  =  val{s,y). 


•  equivalence: 

Here,  x  and  y  may  be  syntactically  distinct,  i.e.,  possibly  x  ^  y;  and,  in  the 
given  state  s,  x  and  y  may  not  be  aliases,  i.e.,  possibly  loc{s,x)  gk  loc(a,y);  but 
x  and  y  are  equivalent :  the  evaluation  of  each  of  them  yields  the  same  location; 
i.e., 

yield($,  x)  =  yield(s,  y), 

and  hence 

val(s,  x)  =  val(s,  y). 

(In  LISP  terminology,  one  would  say  that  eq(x,  y)  it  true.) 
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•  equality: 

Here,  x  and  y  may  be  syntactically  distinct,  i.e.,  possibly  x  ^  y;  in  the 
given  state  «,  x  and  y  may  not  be  aliases,  i.e.,  possibly  /oc(s,  x)  ^  loe(*,y);  and 
x  and  y  may  not  be  equivalent,  t.e.,  possibly  yield(e,x)  yield(i,y);  but  x  and 
y  are  equal,  in  that  they  have  the  same  value;  t.e., 

val(s,x)  —  val(s,y). 

(This  is  the  standard  notion  of  equality  in  most  programming  languages.) 


The  notions  of  aliasing,  equivalence,  and  equality  can  be  illustrated  (for 
the  case  in  which  loe(st  x)  and  loc(s,  y)  are  storage  locations)  by  the  following 
diagrams: 


Figure  3.10 


loc 


Here,  x  and  y  are  aliases. 


Here,  x  and  y  are  equivalent  (but  not  aliases). 


Figure  3.12 


data 
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Here,  x  and  y  are  equal  (but  not  equivalent  and  not  aliases). 

E.  Expressions 

Up  to  this  point,  the  only  expressions  of  the  programming  language  for  which 
the  situational  operators  have  been  defined  are  identifiers;  we  now  extend  the  yield 
and  val  functions  to  other  programming  language  expressions.  For  the  time  being, 
however,  the  function  loc  will  be  defined  only  for  identifiers. 

For  any  expression  e  in  the  programming  language: 

•  the  yield  of  an  expression : 

yield{$,  e)  is  the  location  yielded  by  the  evaluation  of  •. 

•  the  value  of  an  expression: 

val{s,  e)  is  the  data  object  represented  by  yield(s,  e)  after  the  evaluation  of 
•;  thus 

<3.12>  val(s,e)  =  data[s;e,  yield(s,e)). 

In  other  words,  to  determine  the  value  of  •  in  state  s,  we  first  evaluate  e,  producing 
a  new  state  s;  e  and  yielding  a  location  yield{s,  e).  We  then  determine  the  data 
object  data(s;e,  yield(s,e ))  represented  by  this  location  in  the  new  state. 

In  general,  we  assume  that,  if  the  evaluation  of  an  expression  yields  a  defined 
location,  then  the  evaluation  produces  a  defined  state,  and  conversely;  i.e., 

<3.13>  yield{s, •)  =  _|_*  if  and  only  if  *;•=_!_#. 

for  all  states  s  and  expressions  e  in  PL.  This  implies  that,  for  any  expressions 
•i,«2, . . . ,  en  in  PL  and  state  s, 

<3.14 >  if  yield(s ;  eiteat  ...» e.-i,  •<)  =JL«  for  some  »,  1  <  •  <  » 
then  Sf  ei»  eat  . . . » sn  * -■  I  , . 

For  if 

yield(s;eu  eat  •  •  •  t  e<— i,  e»)  =J_*  tor  some  •  between  1  and  n 
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then  (by  <3.13>) 

and  (by  repeated  application  of  <3.2>) 

025  •  •  •  5  —  I  a ‘ 

Informally,  an  expression  e  is  said  to  hare  no  side  effects  if  its  evaluation  in 
a  state  s  produces  a  state  "indistinguishable”  from  t  We  will  define  two  states  $i 
and  «2  to  be  indistinguishable,  denoted  by  *i  w  »2,  if  the  situational  operators 
all  behave  the  same  in  and  82',  i.e.,  if 

<3.15>  loe(sitx)  =  loe(s2,x), 

<3.16>  8tore(sita)  =  store(82,a), 

<3.17>  data($i,a)  —  data(ta,a), 

<3.18>  yield(t  1,9)  =  yte/d(e2,e), 

<3.19>  isdato(tt,a)  if  and  only  if  i*<fata(s2, a), 

<3.20 >  isttore(ti,a)  if  and  only  if  isstore(s2,a), 

<3.21  >  is8trueture(8i,a)  if  and  only  if  isttructure(ta,a ) 

<3.22>  «i  =_|_,  if  and  only  if  «2  =_]_», 

for  all  identifiers  x,  locations  a,  and  expressions  e.  Clearly,  «  is  an  equivalence 
relation. 

We  will  say  that  an  expression  •  hat  no  tide  effects  if  its  evaluation  is  either 
undefined  or  produces  a  state  indistinguishable  from  the  original  state;  i.e., 

if  yield(t ,  e)  then 

The  evaluation  of  an  identifier  will  be  assumed  to  produce  no  side  effects; 
i.e., 


<3.23>  if  yield(»,x)  j^_Lt  then  s;x  «  s, 
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for  all  states  »  and  identifiers  x  in  PL.  (For  the  time  being,  we  ignore  the  pos¬ 
sibility  that  an  identifier  may  denote  a  procedure,  whose  evaluation  can  produce 
side  effects.)  The  definition  of  vol  for  expressions  e  <3.12>,  i.e., 

val(s,  e)  =  data{s;  e,  yield{s,  e)) 

can  now  be  seen  to  be  consistent  with  our  earlier  definition  of  va I  for  identifiers 
x,  t.e., 

val(s,x)  =  data{s,yield(s,x)). 

For  if  yield(s,x)  _t  then,  by  <3.23>,  the  evaluation  of  x  produces  no  side 
effects;  t.e.,  s;x  ss  s,  and  hence,  by  <3.17>, 

data(s ;  x,  yitld(s,  x))  =  data(s,  yicld{s,  x)). 

On  the  other  hand,  if  yield(s,  x)  =_|_t,  then 

data(s;x,  yield{s,x))  =_!_<*=  data(s,  yield(t,x)). 

In  either  case,  the  desired  conclusion  holds. 

The  only  constructs  we  have  introduced  into  the  programming  language  PL 
so  far  are  the  identifiers  and  the  sequencing  operator  We  will  assume  that 
satisfies  the  following  property  . 

•  the  yield  of  a  sequence: 

The  location  yielded  by  the  evaluation  of  eite2  is  precisely  the  location 
yielded  by  the  evaluation  of  e2  after  the  evaluation  of  0j;  t.e., 

<3.24>  yield(s,  eisea)  =  yitld{s,9\,  62). 

This  implies  the  value  of  a  sequence  property 
<3.25>  val(s,  01502)  =  w/(*;«i,  03). 

For, 

val{s,  01502)  =  data[s;{ou93),  yield{»,  01502)) 
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by  the  definition  of 

the  value  of  an  expression  <3.12> 

=  data((»;9i),92,  yield{»,  ones)) 
by  the  sequence  property  <3.1  > 

=  doto((s;ei);e2,  yitld(»\9\,  «3)) 
by  the  yield  of  a 

sequence  property  above  <3.24> 

=  val(s;e it  e2) 

by  the  definition  of  the 
value  of  an  expression  <3.12> 


This  concludes  the  introduction  of  our  descriptive  apparatus.  In  the  following 
sections  we  will  apply  these  notions  to  particular  classes  of  expressions  and  simple 
programming  languages. 


4.  STATIC  EXPRESSIONS 


In  this  section  we  describe  a  very  simple  class,  the  ‘static  expressions,”  whose 
evaluation  produces  no  side  effects  and  involves  no  procedure  calls.  This  class  is 
not  of  great  interest  in  itself,  but  the  discussion  will  illustrate  the  application  of 
our  situational  operators.  Moreover,  static  expressions  will  be  a  component  of 
other,  more  complicated  expressions. 


A.  Pure  Constructs 

Certain  constructs  of  a  programming  language,  such  as  (typically)  arithmetic 
operators,  produce  no  side  effects.  We  will  say  that  a. construct  f(ui,u2,  . . .  ,u*) 
is  pure  if  it  has  the  following  properties: 

•  no  tide  effects : 

The  evaluation  of  a  pure  construct,  if  it  is  defined,  produces  no  side  effects; 
i.e., 

<4.1  >  if  yield{s,  f(«i,e2)  . . .  ,en)) 

then  s;f(ex,e2,  . . .  ,en)  «  «;ei;e2;  ...;e* 

for  all  states  s  and  expressions  ei,  e2,  . . . ,  en  of  PL.  Note  that  the  operators 
•i,  e2,  . . . ,  en  themselves  may  produce  side  effects,  and  that  expressions  are 
evaluated  in  left-to-right  order.  Special  treatment  is  required  for  languages,  such 
as  ALGOL  68,  in  which  the  evaluations  of  t|,  e2,  . . . ,  en  may  be  interleaved. 

•  pure  value: 

The  construct  f  corresponds  to  a  function  fi{d\,da,  . . .  ,dn),  mapping  data 
objects  into  data  objects,  such  that 

< 4.2  >  val(s,  f (e, ,  e2,  . . . ,  en))  = 

fd{val{s,  e,),t >al{s,ei,  e2),  . . .  ,uo/(s;ei;e2  . . .  ;•»_!,  •»)) 

for  all  states  s  and  expressions  #t,  e2,  . ..,  e„  in  PL.  We  assume  that  /* 
is  strict ;  i.e.,  if  any  of  di,d2,  . . . ,  dn  is  the  undefined  data  object  J_4  then 
fd(di,d2,  .  •  • ,  dn)  =_U  as  well. 
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For  example,  the  arithmetic  operators  of  algebraic  languages  and  the  binary- 
tree  functions  left  and  right  are  usually  pure  constructs;  random  number  gener¬ 
ators  and  the  cons  function  of  LISP  produce  side  effects  and  are  not  pure. 

B.  Static  Expressions 

We  now  introduce  static  expressions,  which  consist  of  sequences  of  nested 
pure  constructs  and  identifiers.  More  precisely,  we  define  the  static  expressions 
by  the  following  rules: 

•  every  identifier  x  is  a  static  expression. 

•  if  f  is  a  pure  construct  and  elt  e2,  . . . ,  e„  are  static  expressions  then 

f(ei,  . . en)  is  a  static  expression. 

•  if  «i,  «2,  . . . ,  en  are  static  expressions,  then  eis  «2»  . . .  i  en  is  a  static  expres¬ 
sion. 

For  example,  if  plus(u,  v)  and  times(u,  v)  are  pure  constructs,  then 
times(plus(xtl,  y),  2;x);l 
is  a  static  expression. 

From  this  definition  we  can  prove  the  following  lemma. 

Lemma  (static  expression): 

The  evaluation  of  a  static  expression  e  produces  no  side  effects;  ».e., 

<4.3>  if  yield{s,  •)  then  s;e  »  s, 
for  all  states  s. 

The  proof  is  by  induction  on  the  structure  of  the  expression  •;  we  assume 
inductively  that  the  property  holds  for  all  proper  subexpressions  of  •.  Suppose 
that  yield(s,e)  ^J_e-  The  proof  distinguishes  between  several  cases,  depending 
on  the  structure  of  e. 

Case:  e  is  an  identifier.  Then  s;e  »  s,  because  we  have  assumed  that 
yield(s,a)  ?*J_i  and  that  the  evaluation  of  identifiers  produces  no  side  effects 
<3.23>. 
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Cate:  e  is  of  form  f(ei,  ex,  ....  en),  where  f  is  a  pure  construct  and*  i,#a»  ...»•» 
are  static  expressions.  We  have  assumed  that 

yield(s i  f (si j  e2*  •  •  •  •  en))  I  / . 

it  follows,  because  pure  constructs  produce  no  side  effects  <4.1  >,  that 

S'/  f(ei,  ®2»  •  •  •  »  Sn)  W  Si J  6j|  i  ®n 

and  also  (by  <3.13>)  that 

e,  f(ei,  ®2>  •  •  •  •  Sii)  I  § . 

Hence,  by  <3.22>, 

®1>  ®2»  •  •  •  »®n 

and,  by  <3.14>, 

yie/d(«;  ej ;  . . . ;  e,_, ,  e,)  ^±t 

for  each  *,  1  <  t  <  ». 

Then 

Sf  f(ei ,  62*  •  •  •  «  6n)  W  Sf  8j ,  •  •  ■  ,  6^ 

by  <4.1  >  again 


««;eu  ...;e< 

by  repeated  application 
of  the  induction  hypothesis 
(and  the  transitivity  of  «) 


«  s. 


Note  that  we  were  able  to  apply  the  induction  hypothesis  above  only  because 
we  had  established  that 


yield{s;et;  i,  e.) 
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for  each  s'. 

Cate:  •  it  of  form  «i;«2;  •  ••*«>  where  *1,421  ...,•»  are  italic  expressions. 
We  have  assumed  that 

yield(s,  ei;e2; 

thus,  by  <3.13>, 

It  follows  (by  <3.14>)  that 

l/ie/d(«;ei;e2;  . . .  ;e,_i,  e,)  =^_L* 

for  each  t  between  1  and  n. 

Then 

^»(®1»®2i  •  •  •  i®»)^  *i®li®2t  • • • » ®» 

by  repeated  application  of 
the  sequence  property  <3.1  > 

ft#  a;  ei»®2»  •  •  •  5  ®»‘ 

by  repeated  application  of 
the  induction  hypothesis 

» t. 

Again,  we  needed  to  establish  that 
yields', •  i;e2;  ...;®<-i,  «.) 
for  each  i,  to  apply  the  induction  hypothesis.  | 

Corollary.  If  •  is  a  static  expression,  then 
<  4.4 >  val(t,  •)  =  data{t,  yield{s,  •))  for  every  state  s. 
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For,  by  the  definition  of  the  value  of  an  expression, 
val{$ ,  e)  =  data{s;  e,  yield{»,  •)). 

In  the  case  that  yield(t,e)  ^_Lc,  the  lemma  tells  us  that  »;•  »  *  and  hence 
(by  <3.17>) 

data(s;e,  yield(s,e))  =  data(s,  yield(s,e)). 

On  the  other  hand,  if  yield(a,  e)  =_]_*,  then 

data(s,e,  yield(a,e))  =  _|_4  —  data($,  yield(t,*)) 

Corollary.  If  f(uj,  ua,  . . . ,  un)  is  a  pure  construct  and  ei,ea,  are  static 

expressions,  then 

<4.5>  val{$, f(ei, e2,  ....  en))  =  fi{val{a,e j),  va/(s,ea),  . . . ,  val{$,mn)), 

where  /<*  is  the  data  object  function  corresponding  to  f. 

Proof: 

We  have  that 

oa/(s,f(ei, ea,  .  ..,«*))  = 

fd{val(s,  et),  val(s,Bi,  e2),  ...,vai(i;e t,ea,  •») 

by  the  pure- value  property  <4.2>.  If  we  can  show  that 
*;ei;e2;  . . . ;  e,- »  s 

for  each  i,  1  <  «  <  »,  this  will  imply  the  desired  result,  by  <3.17>  and  <3.18>. 
In  the  case  that 

yte/d(s,  f(ei,  62,  •  •  • ,  en  j)  v-  I  § . 
we  have  (by  <3.13>)  that 

SJ  f(ej,  62,  •  •  • «  6n) 


40  STATIC  EXPRESSIONS 

and,  hence,  because  pure  constructs  produce  no  side  effects  <4.1  >  and  by  <3.22  > , 
that 

®li  ®2»  •••#•» 

By  <3.14>  then,  this  tells  us  that 

yield(s',9t  i,  •<)  ^±t 

for  each  t,  1  <  *  <  n.  Finally,  by  repeated  application  of  the  static  expression 
lemma  itself,  we  conclude  that 

s;«i;  . . .  «  s 

for  each  t,  implying  the  desired  result. 

On  the  other  hand,  in  the  case  that 

yield{$,  f(ei,  . . •»))  =J_|, 

we  would  like  to  show  that 

fd(va i(«,e,),t/a/(s,ea),  . . . ,  vo/(s,  en))  =_U- 

If  val(s,et)  =  I  d  for  any  t,  the  desired  result  follows  from  the  strictness  of 
<4.2>;  so  we  can  assume  va/(s,e,)  j^A-d  for  each  s.  Consequently, 
yield(»,ei)  9^  |  /  for  each  t,  by  the  definition  of  the  va/  operator  <3.10>.  By 
repeated  application  of  the  lemma,  then,  we  have  that 

«;®i  «  s 
s;ei;«2  »  » 

for  each  s’,  by  the  transitivity  of  «,  implying  the  desired  result.  | 

To  prove  the  Hoare  assignment  axiom,  the  right-hand  side  of  an  assignment 
statement  will  be  restricted  to  be  a  static  expression.  But  first  we  must  introduce 
the  assignment  statement  itself. 


5.  THE  ASSIGNMENT  STATEMENT 


We  are  now  ready  to  define  the  semantics  of  a  simple  assignment  statement  in 
terms  of  the  situational  operators.  The  statement  we  describe  is  only  a  prototype: 
different  programming  languages  provide  different  varieties  of  assignment.  For 
these  languages,  our  definition  can  be  altered  accordingly. 


An  assignment  statement  in  PL  is  of  form 


x«-e, 


where  x  is  an  identifier  and  e  is  any  expression  in  PL.  The  execution  of  this 
statement  in  a  state  s  takes  place  in  three  stages: 


(1)  The  location  /oc(*,x)  associated  with  the  identifier  x  is  determined.  It 
is  assumed  that  this  step  produces  no  side  effects.  If  Ioe(s,x)  is  not  a  storage 
location,  an  “error  condition”  occurs;  in  this  case,  we  will  say  that 


(2)  The  expression  e  is  evaluated,  yielding  the  location  yitld[s,  e)  that  repre¬ 
sents  the  value  of  e,  and  producing  a  new  state  s;e.  (In  general,  the  evaluation 
of  •  may  produce  side  effects.) 


(3)  The  location  yield(s,e)  is  stored  in  the  location  loc(s,  x),  producing  the 
new  state  s;  x  «■  e.  The  location  yielded  by  the  evaluation  of  the  assignment 
statement  itself  is  the  same  as  that  yielded  by  the  evaluation  of  e. 


We  illustrate  this  process  diagrammatically  as  follows: 


41 


42  THE  ASSIGNMENT  STATEMENT 


Figure  5.1 


at*  at  s;e  at  $;  x  «•  • 


Note  that  in  the  second  picture,  correponding  to  the  state  *;  e,  the  toe  link  leading 
from  x  and  the  store  link  leading  from  ai  have  been  changed;  this  is  because  the 
evaluation  of  e  may  have  side  effects  that  can  change  any  of  the  links  at  state  a. 

The  information  suggested  by  the  above  diagram  is  conveyed  more  precisely, 
if  perhaps  less  readably,  by  the  following  assignment  axioms.  These  express  the 
effect  of  the  assignment  statement  on  each  of  the  situational  operators: 

•  principal  axiom 

<5.1  >  store(s ;  x  *  e,  loc{s,  x))  =  yield(s,  e)  if  isstore(s,  loe[s, x)) 

for  all  states  s  and  identifiers  x  and  expressions  e  in  PL.  The  above  axiom 
describes  the  change  that  is  the  intended  effect  of  the  assignment  statement.  It 
is  also  necessary  to  introduce  frame  axioms  indicating  that  no  other  changes  are 
produced  by  the  assignment. 

•  frame  axioms 

< 5.2 >  loc(s ;  x  «•  e,  y)  =  loc(s;  e,  y) 
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<5.3>  store($ ;  x  «■  e,  t)  =  atore{a;a,  £)  if  l  loe(s,  x) 

<5.4>  dota(a;x  +  e,  l)  —  data(a,9,  f)  if  s*cfota(s;e,  £) 

<5.5>  iedoto(a;x  *  e,  i)  if  and  only  if  iadata(s;  9,  £) 

<5.6>  iastore(s]  x  *■  9,  t)  if  and  only  if  isstore(»;9,  /) 

<5.7>  ia$trueture(»;x  «■  e,  i)  if  and  only  if  isstructure(s;9,  £) 

for  all  states  *,  identifiers  x  and  y,  expressions  e,  and  locations  t,  such  that 
isstore(s,  loc(t,  x)). 

The  axioms  express  that  only  the  atore  link  of  loc[a,x )  can  be  altered  by  the 
execution  of  the  assignment  itself.  Note  that  other  links  can  be  altered  by  the 
evaluation  of  e.  Also  note  that,  although  the  assignment  is  assumed  to  leave  the 
data  link  of  data  locations  unchanged,  it  can  indirectly  alter  the  data  link  of  other 
locations.  For  example,  consider  the  configuration  illustrated  below: 


Figure  5.2 


Here,  evaluating  an  assignment  statement  x  *■  e  will  alter  the  store  link  of 
as.  Consequently,  it  will  indirectly  alter  the  data  link  of  the  storage  locations  a*, 
as,  and  a\,  by  virtue  of  the  relationship  <3.7>  we  have  assumed,  ess., 

data($,  i)  =  data[$,  store(a,  £))  if  iaatore(s,  £). 
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Structure  locations  can  also  have  their  data  links  altered  indirectly  by  assignment 
statements,  as  will  be  seen  in  the  forthcoming  Part  II. 

Because  we  regard  assignment  statements  as  expressions  which  may  appear 
as  subexpressions  of  other  expressions  [e.g.t  we  consider  2  ♦  (x  «■  (x  -  1))  to  be 
a  legal  expression),  we  need  an  axiom  that  defines  the  location  representing  the 
value  of  an  assignment  statement. 

•  yield  axiom: 


<5.8>  yield(s,  x  «■  e)  =  yield{$,  e)  if  isstore(e,  loe(»,  x)) 

for  all  states  s,  identifiers  x,  and  expressions  e.  In  other  words,  the  location 
yielded  by  the  evaluation  of  the  assignment  statement  itself  is  the  same  as  that 
yielded  by  the  evaluation  of  e. 

•  illegal  axiom : 


<5.9>  «;x  «■  e  =JL«  if  not  isstore(s,  loc(»,  x)). 

•  undefined  axiom: 


<5.10>  «;x«-e=J_,  if  s;e  =J_,. 

In  other  words,  if  x  is  not  associated  with  a  storage  location  when  the  assignment 
is  executed,  an  error  condition  is  produced;  and  if  the  evaluation  of  •  in  state  e 
is  undefined,  then  the  evaluation  of  the  assignment  statement  is  also  undefined. 

Let  us  illustrate  the  use  of  these  axioms  to  prove  a  simple  property  that  is 
beyond  the  expressive  power  of  the  Hoare  rules.  We  show  that  if  •  is  an  expression 
that  creates  no  aliasing,  then  x  *  e  also  creates  no  aliasing;  i.e., 

Lemma  (no  aliasing): 

Suppose  e  is  an  expression  in  PL  with  the  property  that 
(*)  if  loe{»,  x)  ^  loc(»,  y)  then  /oc(i;  e,  x)  ^  loe(» ;  e,  y) 


THE  ASSIGNMENT  STATEMENT  45 
for  all  states  s  and  identifiers  x  and  y.  Then 

if  loc(t,  x)  5^  loc(t,  y)  then  loc(s;z  *■  •,  x)  /  loc(o;z  +  •,  y), 
for  all  states  s  and  identifiers  x,  y,  and  a,  such  that 
is»tore(t,  loc(»,  z)). 


Proof 

Assume  that  e  has  the  above  property  (*)  and  that 
loc[st  x)  ^  loc(S|  y). 

Then 

loc{s\  z  *■  e,  x)=  loe(s;  e,  x) 

by  the  frame  axiom 
for  assignment  <5.2> 

5* loc(s}e ,  y) 

by  the  assumed  property  (*) 

=  loe(s;  z*-e,  y) 

by  the  frame  axiom  for  assignment,  again. 

In  short, 


loc(s;  z  «•  e,  x)  loc{» ;  z  «■  e,  y).  | 


6.  ASSERTIONS  WITHIN  STATES 


Our  situational  operators  can  describe  properties  of  a  program  in  terms  of 
machine  locations.  Often  it  is  necessary  to  express  such  properties  in  terms  of 
assertions,  where  an  assertion  is  a  relationship  among  the  values  of  the  program’s 
identifiers  that  is  intended  to  hold  when  the  execution  reaches  a  certain  point  in 
the  program.  In  this  section  we  connect  these  two  levels  of  description,  assertions 
and  situational  operators. 


A.  Assertion  Language 

An  assertion  will  customarily  involve  constructs  from  both  the  programming 
language  and  the  program’s  subject  domain.  For  example,  suppose  we  have  a 
program  that  is  intended  to  assign  to  an  identifier  z  the  greatest  common  divisor 
gcd(x,  y)  of  (the  values  of)  two  identifiers  x  and  y,  without  changing  x  and  y. 
Then  we  might  wish  to  assert  that,  when  the  execution  of  the  program  terminates, 
the  following  relationship  is  true: 

z  =  max{u :  u|x  and  u|y}. 

Here  x,  y,  and  z  are  identifiers  in  the  programming  language;  the  other  symbols 
max,  {u: . . . },  |,  and  and  are  constructs  from  the  theory  of  the  program’s  subject 
domain.  • 

In  general,  then,  we  assume  we  have  a  domain  language  DL  for  expressing 
sentences  about  the  program’s  subject  domain;  we  would  like  to  extend  this 
language  to  form  an  assertion  language  AL  that  also  includes  identifiers  and  pure 
constructs  from  the  programming  language  PL.  This  extension  can  be  achieved 
with  no  confusion,  because  we  have  adopted  disjoint  vocabularies  for  the  domain 
language  and  the  programming  language.  In  our  discussion,  subject  domain 
constructs  will  always  be  denoted  by  italic  (italic)  characters  while  programming 
language  constructs  will  be  denoted  by  boldface  (boldface)  characters. 

The  truth  of  an  assertion  in  AL  is  only  meaningful  with  respect  to  a  state  a 
of  the  execution;  each  programming  language  identifier  x  in  the  assertion  is  then 
taken  to  refer  to  the  data  object  val(s,  x)  in  the  program’s  domain.  For  example, 
the  above  assertion 

a  =  max{u :  u|x  and  u |y) 
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is  true  in  a  state  s  if  the  sentence 

val(s,z)  =  maz{u :  u|vaf(*,x)  and  u|val(«,y)} 
is  true  in  the  subject  domain. 


B.  The  Extended  val  Operator 

To  discuss  the  truth  of  a  sentence  in  the  assertion  language,  we  allow  assertion- 
language  expressions  among  the  objects  we  consider,  and  extend  the  situational 
operator  val  to  apply  to  such  expressions.  We  will  then  say  that  an  assertion  P 
holds  in  a  state  s  if  val{s,  P)  =  true. 

The  extension  of  the  val  operation  is  similar  to  Tarski’s  definition  of  the  truth 
of  sentences  in  logic.  We  will  pay  special  attention  to  quantified  expressions  in  the 
assertion  language.  We  want  to  say  that  an  expression  VuQ  has  value  true  in  a 
state  s  if  Q  has  value  true  in  s  regardless  of  the  value  of  the  dummy  variable  u.  To 
formalize  this  definition,  we  introduce  the  notion  of  a  substantiation  if,  a  function 
that  maps  some  of  the  variables  of  the  domain  language  into  data  objects  in  D.  We 
will  add  a  substantiation  as  a  third  argument  to  the  val  operator,  val(s,  t,  ^);  our 
intention  is  that  the  substantiation  rf>  will  supply  the  values  of  any  free  variables 
in  the  assertion  language  expression  t.  We  will  then  be  able  to  define  the  val  of 
VuQ,  say,  in  terms  of  the  val  of  Q,  for  appropriate  substantiations. 

Let  us  be  more  precise.  If  uit  «2,  . . . ,  u*  are  variables  in  DL  and  dj,  da,  . . . ,  d* 
are  data  objects,  then  the  list 


ir.  (ui  «-  di,U2  «-  da,  . . .  ,u*  «-  d*) 


is  a  substantiation.  We  do  not  assume  that  the  variables  uj.ua,  . . . ,  u*  are 
distinct,  and  we  do  regard  the  order  of  the  list  as  significant.  We  will  say  that 
the  variables  ui,  ua,  . . . ,  u*  are  substantiated  by  i>.  We  denote  by  ( )  the  empty 
substantiation,  which  substantiates  no  variables.  If  u  is  a  variable,  d  is  a  data 
object,  and  i>  is  as  above,  we  denote  by  (u «-  d)  o  if  the  extended  substantiation 


(u  «-  d, u i  <-  di,i<2  «-  da,  d*). 


Henceforth,  we  will  regard  val  as  a  situational  function  val{s,  t,  if)  of  three 
arguments:  a  state  s,  an  expression  t  of  AL,  and  a  substantiation  if.  We  consider 
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the  earlier  notation  val(»,  t)  with  two  arguments  as  an  abbreviation  for  val[$,  t,  {)), 
where  ( )  is  the  empty  substantiation;  i.e., 

<6.1  >  val{s,  t)  =  val{s,  t,  ( )). 

We  define  the  language  AL  and  the  extended  vat  function  according  to  the 
following  rules: 

•  As  usual,  in  the  undefined  state  J_(, 

<6.2>  val{_ L„  t,  it)  =J _d 

for  any  expression  t  in  AL  and  any  substantiation  i> 

•  A  constant  c  in  DL  is  a  constant  of  AL  and  is  associated  with  a  data  object  cj 
in  D.  Thus, 

<6.3>  val(s,  c,  i>)  =  Ci 

for  all  (defined)  states  s  and  all  substantiations  it. 

•  All  variables  of  DL  are  variables  of  AL.  For  distinct  variables  u  and  v  in  DL, 
<6.4>  val(s,  u,  { ))  =  ±d 

<6.5>  val(s,  u,  (u  d)  o  it)  =  d 

<6.6>  val(s,  u,  {v  4-  d)o  it)  =  val(s,  u,  it) 

for  all  (defined)  states  s,  data  objects  d  and  substantiations  it.  Note  that  if 
a  variable  occurs  more  than  once  in  a  substantiation,  the  leftmost  occurrence 
predominates;  e.g., 

val{s,  u,  (u  4-  di,u  *-  d2,u  *-  da))  =  d\. 

On  the  other  hand,  if  a  variable  in  DL  is  not  substantiated  at  all,  its  value  is 
undefined;  thus  if  u  is  distinct  from  variables  v  and  w,  then 

val{t,  u,  {v  *—  d\tw  4—  d2))  =_!_*. 

•  If  x  denotes  an  identifier  in  PL,  then  x  is  in  AL  and 
<6.7>  val{»,  x,  ^)  =  val{»,  x) 
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for  all  states  a  and  substantiations  if.  Thus,  the  value  of  an  identifier  is  independ¬ 
ent  of  the  substantiation  if. 

•  A  function  symbol  g  in  DL  is  a  function  symbol  of  AL  and  is  associated  with  a 
strict  function  g d  over  the  set  D  of  objects;  thus 

<6.8>  vol{s, g(ti,t2,  .... tn), if)  = 

9d{val{s, tuif), val(e, t2> if),  .... val(e, tn, if)) 

for  all  states  s,  expressions  ti,t2,  . . . ,tn  in  AL,  and  substantiations  if. 

Similarly,  a  predicate  symbol  in  DL  is  associated  with  a  strict  function  over 
the  set  D  of  objects;  a  similar  definition  applies. 

•  If  f  denotes  a  pure  construct  in  PL  ,  then  f  is  a  function  symbol  in  AL  and  is 
associated  with  a  strict  function  /<*  over  the  set  D  of  data  objects  (see  <4.2>); 
then 

<6.9>  val(3,f{tut2,  ...tn),if)  = 

fd{val[s,  ,  i>),  val(s,  t2,  if),  ,  val{$,  tn,  if)) 

for  all  states  s,  expressions  ti,t2,  . . .  ,tn  in  AL,  and  substantiations  if. 

•  The  value  of  a  logical  expression  of  form  ~>P  in  AL  is  the  negation  of  the  value 
of  P,  i.e., 

<6.10>  val(8,->P,if)  ==  not(val(»,P,if)) 

for  all  states  «  and  substantiations  if. 

•  The  value  of  a  logical  expression  of  form  P  A  Q  in  AL  is  the  coigunction  of  the 
values  of  F  and  Q-,  i.e., 

<6.1 1  >  val{8,P AQ,if)  =  val[8,P,if)  and  val(8,Q,if). 

The  other  logical  connectives  are  treated  similarly. 

•  The  value  of  a  quantified  expression  VzP  in  AL  (where  z  is  a  variable  in  DL 
and  P  is  a  logical  expression  in  AL)  is  true  if  the  value  of  P  is  true  regardless  of 
how  we  substantiate  z;  more  precisely: 


<6.12>  val{a,VzP,i>)  =  true 


50  ASSERTIONS  WITHIN  STATES 


if,  for  every  data  object  d,  val{$,  P,  (z  *-  d)  of)  =  true 

<  6. 13  >  val{s,  VzP,  if>)  —  false 

if,  for  some  data  object  d ,  val{s,  P,  (z  *-  d)  o  ifr)  =  false 

<6.14>  vo/(s,VxP,^)  =J_*  otherwise 

Note  that  the  value  of  VxP  will  be  undefined  if  P  is  undefined  for  some  substan¬ 
tiations  but  P  is  never  false. 

Because  3zP  is  logically  equivalent  to  -iVx-»P,  the  above  definition  suggests 
a  definition  of  val{s,  3 zP,  rpy,  i.e., 

<6.15>  3xP,  i/>)  =  val[s,  -iVx-iP,  $). 


•  The  value  of  the  set  constructor  {u:  P)  in  AL  is  a  set  of  all  data  objects  in  D 
that  satisfy  P;  more  precisely: 

<6.16>  val(s,  {u:  P),  V»)  =  the  set  of  all  data  objects  d  in  D  such  that 

val(s,  P,  (u  «-  d)  o  =  true 

If  the  domain  language  includes  other  constructs,  then  val  must  be  extended 
for  them  as  well.  Note  that  we  do  not  include  the  “impure”  constructs  of  the 
programming  language  PL,  t.e.,  those  constructs  with  side  effects,  in  the  assertion 
language  AL. 

We  will  need  the  following  simple  properties  of  the  extended  val  operator. 

•  The  value  of  an  expression  t  in  DL  (which  contains  no  identifiers  of  PL)  is 
independent  of  the  state;  t.e., 

<$.17>  val{s,  t,  =  ua/(s',  t,  V) 

for  all  states  s  and  s'  and  substantiations  i>. 

•  The  value  of  a  static  expression  •  in  PL  is  independent  of  the  substantiation; 
i.e., 

<6.18>  val(s,  a,  if>)  =  vol(s,  •) 

for  all  states  s  and  substantiations  i>.  These  properties  can  be  proved  from 
the  definition  of  the  extended  val  operator  by  induction  on  the  structure  of  the 
substantiations  and  expressions. 
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C.  The  □  and  0  Operators 


Now  that  we  have  extended  val  to  apply  to  expressions  in  the  assertion 
language,  we  can  define  two  situational  operators,  □  and  o,  for  expressing  that 
an  assertion  P  holds  in  a  state  s: 


<6.19> 


{true  if  val(s,  P)  =  true  or  val(s,  P)  =  _Ls 
false  if  vol(s,  P)  =  false 


In  short,  □(*,  P)  holds  if  P  is  not  false  in  s. 


<6.20> 


0(3,  P) 


true  if  va l(s,  P)  =  true 

false  if  val{s,P)  =  false  or  val{s,P )  =_[_* 


In  short,  o(s,  P)  holds  if  P  is  true  in  s.  Note  that  □  and  o  are  always  true  or 
false;  they  are  never  undefined  even  if  their  arguments  are.  Furthermore,  they 
satisfy  the  usual  dualities  of  modal  logic: 


<6.21  >  □(«,-.P)  =  -iO(s,P) 

<6.22>  o(s,-.P)  =  -.□(«,  P). 

These  operators  are  distinct  from  the  [e]P  and  <  e  >  P  of  dynamic  logic  (Pratt 
[1976])  in  that  they  are  applied  to  states  s  rather  than  program  segments  a. 

Typically,  the  □  operator  is  used  to  express  the  partial  correctness  of  a 
program,  the  o  operator  to  express  its  total  correctness.  For  example,  to  represent 
a  statement  in  Hoare’s  logic  of  form 


where  a  is  a  program  segment,  we  write 

if  o(s,  P)  then  □(*;«,  Q)  for  all  states  s. 

This  sentence  expresses  the  partial  correctness  of  the  program  segment  •  with 
respect  to  the  input  assertion  P  and  the  output  assertion  <?;  it  is  automatically 
true  if  the  program  segment  e  fails  to  terminate;  i.e.,  if  «;•  because  then 


vol(s;e,  Q)  =J_* 
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and,  therefore, 

□(*;«,  Q)  =  true, 
by  the  definition  of  □,  <6.19>. 

On  the  other  hand,  to  express  the  total  correctneu  of  e  with  respect  to  the 
same  assertions  P  and  Q,  we  write 

if  0(s,  P )  then  o(s;e,  Q)  for  all  states  ». 


7.  PROVING  HOARE’S  ASSIGNMENT  AXIOM 


We  have  now  introduced  the  concepts  necessary  for  expressing  the  classical 
Hoare  assignment  axiom  and  the  restrictions  under  which  it  is  true.  One  virtue  of 
this  situational-calculus  approach  is  that  it  allows  us  to  formulate  these  restric¬ 
tions  explicitly  in  a  mathematical  language  and  to  deal  with  them  in  the  same 
framework  in  which  we  conduct  all  our  reasoning.  In  this  section,  we  will  prove 
the  “assignment  theorem,”  that  the  Hoare  axiom  is  true  under  the  appropriate 
restrictions. 

Usually  the  axiom  is  expressed  as 
{P«.(x«-e)}x*-e{P}, 

where  P  is  an  assertion,  x  is  an  identifier,  and  e  is  an  expression  in  PL.  Recall 
that  P  *o  (x  *-  e)  stands  for  the  result  of  replacing  all  free  occurrences  of  x  in  P 
by  e.  The  axiom  indicates  that  if  the  assertion  P«(x<-s)  holds  before  executing 
the  assignment  x*-e,  and  if  the  execution  terminates,  then  the  assertion  P  holds 
afterwards. 

Expressed  in  terms  of  the  situational  operator  □,  the  axiom  reads 

<7.1  >  if  0(5,  P<»(x  <-  e)) 
then  □(«;  x  «■  e,  P) 

for  all  states  s,  where  d(j,  Q)  means  that  the  assertion  Q  is  either  true  in  $  or 
undefined  in  ». 


A.  Problematic  Phenomena 

In  the  section  on  MOTIVATION,  we  have  given  many  situations  arising  in 
actual  programming  languages  for  which  the  above  axiom  is  false.  In  this  section 
we  will  review  those  phenomena,  and  specify  the  restrictions  for  precluding  them. 

•  the  expression  e  mutt  be  static: 

This  restriction  prohibits  assignment  statements  such  as 

x  *  (y  *  *) 


S3 
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Such  statements  violate  the  assignment  axiom.  For  example,  suppose  *=*  is  the 
domain  language  equality  predicate.  Then,  for  a  state  »  in  which  y  =  1,  it  will 
be  true  that 

(y  =  lMx «- (y  *  2)) ), 


«.e., 


□(s,  y  =  1). 

However,  after  executing  the  assignment,  y  will  be  2;  t.e., 

□(«;x-(y  *-2),  y  =  2); 
so  it  will  be  false  that 

□(*;x-(y -2),  y  =  1), 
contradicting  the  axiom. 

•  P  must  be  an  assertion  in  the  assertion  language  AL : 

Otherwise,  P  might  be  a  condition  such  as 

"there  exists  an  identifier  whose  value  is  2.” 

Here  P  contains  no  occurrences  of  x  at  all.  Therefore,  if  s  is  a  state  in  which  x 
is  the  only  identifier  whose  value  is  2,  it  is  true  that 

□(«,  P*{x«-  0)), 


□(«,  P )• 

However,  after  executing  the  assignment  x  «•  0,  there  is  no  identifier  whose  value 
is  2;  therefore,  it  is  false  that 

□(«;x  *  0,  P), 

contradicting  the  axiom. 
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•  x  must  not  be  an  alias  of  any  other  identifier  that  occurs  in  P: 

For,  suppose  x  and  y  are  aliases,  and  s  is  a  state  in  which  y  =  0.  Then  if 
we  execute  the  assignment  x «- 1,  y  will  be  changed  to  1.  In  other  words,  it  is 
true  that 


(y  =  0)*o(x«-  1)), 


i.e., 


y  =  o), 

but  false  that 

□(*;x  «■  1,  y  =  0), 
contradicting  the  axiom. 

•  x  must  not  be  "pointed  to"  by  any  expression: 

For,  suppose  a  configuration  such  as  the  following  exists  in  state  s; 


Figure  7.1 


In  other  words,  the  location  ft  to  which  the  identifier  x  is  bound  is  the  location 
yielded  by  the  evaluation  of  the  identifier  y.  Then  x  and  y  both  have  the  same 
value,  0  in  this  case,  because  the  store  operator  transmits  the  value  (<3.7>  and 
<3.11  >).  If  we  execute  the  assignment  x  «•  1,  we  indirectly  alter  the  value  of  y, 
to  1.  In  other  words,  it  is  true  that 


(y  =  0)o(x «-  l)), 
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i.e., 


□(«,  y  =  0), 
but  false  that 

0(s;x-  1,  y  =  0), 

contradicting  the  axiom.  Thus,  problems  may  arise  if  some  identifier  y  in  the 
assertion  P  “points  to”  x. 

Similar  problems  arise  if  x  is  “pointed  to”  by  some  identifier  in  the  expression 
e.  For  example,  suppose  that  in  state  $  above,  instead  of  executing  x*  1  we 
execute  x  «■  y.  Then  the  configuration  in  state  s ;  x  *■  y  is 


Figure  7.2 


Here,  x  is  bound  to  a  circular  tree;  although  we  have  not  yet  defined  the  data 
object  represented  by  such  a  structure,  it  is  certain  that  this  object  is  not  0.  Thus, 
although  it  is  true  initially  that 

0(s,  (x  =  0)«(x*-y)), 


s.e. 


□(s,  y  =  0), 
it  is  not  true  that 

D(s;x«-y,  x  =  0), 


thereby  contradicting  the  axiom.  Here,  a  problem  occurs  because  x  was  pointed 
to  by  an  identifier  in  e,  not  in  P. 
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Finally,  problems  can  occur  if  x  is  "pointed  to"  by  an  expression  other  than 
an  identifier.  For  example,  suppose  that  the  following  configuration  occurs  in 
state  s: 


Here  x  is  an  identifier  (whose  value  is  0),  e  is  any  static  expression  in  PL  that 
contains  no  occurrence  of  x,  and  a  is  a  structure  location  whose  left  descendant  is 
loe[»,  x).  The  evaluation  of  the  PL  expression  left(e)  yields  the  location  loc(»,  x). 
Thus,  in  this  state,  left(e)  =  0.  If  we  then  execute  the  assignment  x  *  a,  we 
create  the  following  configuration  in  «;  x  «■  e 


Note  that  in  this  configuration  left(e)  0.  Hence,  while  it  is  true  that 
□(«,  (left(e)  =  0)  *q(x  4-  e)), 
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«.e.,  (because  x  does  not  occur  in  e), 

□(«,  left(e)  =  0), 
it  does  not  follow  that 

□(s;x  *  e,  left(e)  =  0), 
contradicting  the  axiom. 

Surprisingly  enough,  no  damage  is  done  if  x  is  the  alias  of  some  other 
identifier  in  e.  For  example,  suppose  that  x  and  y  are  aliases,  and  $  is  a  state  in 
which  x  (and  y)  are  0.  Then,  if  we  execute  the  assignment  x  «-  y+ 1,  x  (and  y) 
will  both  be  changed  to  1.  In  other  words,  it  is  true  that 

o(s,  (x=  l)<»(x«-y+l)), 

s.e., 

□(s,  y+1  =  1), 
but  it  is  also  true  that 

□(*;x«-y+l,  x  =  1), 
as  the  axiom  requires. 


B.  Accessibility 

The  informal  notion  of  ‘pointing  to”  that  we  used  casually  in  the  last  section, 
will  be  formalised  by  introducing  a  concept  of  "accessibility*  in  the  forthcoming 
Part  II  of  this  paper,  on  data  structures.  Roughly  speaking,  we  will  say  that  a 
location  p  is  accessible  from  a  location  a  (in  a  given  state)  if  there  is  some  wqy 
of  reaching  p  from  a  by  applying  a  possibly  empty  sequence  of  store  operators  or 
other  data  structure  operators.  For  example,  consider  the  following  configuration: 
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a 


store 


Figure  7.5 


store 


Here,  P  is  accessible  from  a,  but  7  is  not. 

Some  more  examples:  if  p  =  store(s,  a)  in  a  state  »,  then  p  is  accessible  from 
a  in  8]  and  if  p  and  a  are  identical,  then  P  is  accessible  from  a.  Furthermore,  if 
two  identifiers  w  and  x  are  aliases,  then  loc{s,  x)  is  accessible  from  loc(s,  w). 

An  expression  e  in  PL  will  be  said  to  point  to  a  location  a  (in  a  state  »)  if  a 
is  accessible  (in  *)  from  the  location  yield(s,  e)  yielded  by  the  evaluation  of  e.  On 
the  other  hand,  a  location  will  be  said  to  be  isolated  (in  s)  if  it  is  not  pointed  to  by 
any  expression  in  PL.  Note  that  it  is  possible  for  an  identifier  to  have  aliases  but 
still  be  bound  to  an  isolated  location;  e.g.,  we  may  have  loc(s,x)  =  loc(»,  y),  for 
two  distinct  identifiers  x  and  y,  where  loc(s,  x)  is  a  storage  location  not  accessible 
from  any  location  other  than  itself. 

Although  we  do  not  actually  define  accessibility  formally  until  the  forthcom¬ 
ing  Part  II,  we  can  state  the  one  “accessibility  property”  that  we  will  need  to 
prove  the  assignment  theorem.  Then,  in  Part  II,  we  will  prove  this  property  as  a 
lemma. 

First,  let  us  define  a  static  assignment  to  be  any  assignment  x  *•  e  in  which 
•  is  a  static  expression. 

Now,  to  illustrate  the  accessibility  property  assume  that  the  following  configuration 
exists  in  state  $: 
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a 


data 


x  • — ' 


loc 


Figure  7.6 


store 


Here,  a  is  any  location  and  loc(s,x)  is  a  storage  location.  Then,  if  loc(s,  x)  is 
not  accessible  from  a,  a  static  assignment  x  «■  •  cannot  alter  the  data  object 
represented  by  a. 

In  terms  of  our  situational  operators,  this  is  expressed  as  follows. 

Static  accessibility  property.  Suppose  s  is  a  state,  x  is  an 
identifier,  and  e  is  a  static  expression  in  PL.  If  loc[$,  x)  is  not 
accessible  from  some  location  a  in  state  s,  then 


<7.2 >  dota(s;x  «■  e,  a)  =  data(s ,  a). 

This  is  actually  a  special  case  of  the  following  more  general  statement,  which 
applies  to  nonstatic  expressions  e  as  well. 

Accessibility  property.  Suppose  s  is  a  state,  x  an  identifier, 
and  e  is  any  expression  in  PL.  If  loc($,x)  is  not  accessible 
from  some  location  a  in  state  «;  e,  then 

<7.3>  data(s;x  «■  e,  a)  =  dato(s;0,  a),  and 
<7.4>  loc(s,  x)  is  not  accessible  from  a  in  state  s;x  «■  m. 


C.  Static  Assignment  Theorem 


We  are  now  is  a  position  to  state  the  restricted  Hoare  axiom  as  a  theorem. 
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Theorem  (Static  Assignment):  Let  j  be  a  state,  x  an  identifier,  e  a  static  expres¬ 
sion  in  PL,  and  P  an  assertion  in  AL,  such  that 

(a)  x  is  not  an  alias  of  any  other  identifier  that  occurs  in  P\  i.e.,  loc{», x)  jA 
loc(s,  w)  for  any  identifier  w  distinct  from  x  that  occurs  in  P. 

(b)  loc{$,  x)  is  isolated. 

Then  we  have 

<7.5>  if  d(s,  P«(x  «-  •)) 
then  D(s;x  «•  e,  P), 

The  restriction  (b)  above  is  stronger  than  necessary,  but  it  eliminates  with 
a  single  stroke  all  the  problematic  phenomena  we  discussed  involving  expressions 
pointing  to  /oc(s,x). 

The  proof  of  the  theorem  relies  directly  on  the  following  lemma. 

Lemma  ( static  assignment ):  Let  s  be  a  state,  x  an  identifier,  e  a  static  expression 
in  PL,  t  an  expression  in  AL,  and  0  a  substantiation  such  that 

(a)  x  is  not  an  alias  of  any  other  identifier  that  occurs  in  t, 

(b)  /oc(s,x)  is  isolated. 

Then  we  have 

<7.6>  if  val(s; x  «■  e,  t,  iff)  ^ JLd 

then  val(s;  x  *■  e,  t,  $)  —  val(s,  t  <»(x  «-  e),  VO- 

Intuitively,  the  lemma  asserts  that,  under  suitable  restrictions,  the  value  of 
the  expression  t  after  executing  the  assignment  will  be  the  same  as  the  value 
of  t 1  before,  where  t1  is  the  expression  obtained  from  t  by  replacing  every  free 
occurrence  of  x  by  e.  The  third  substantiation  argument  V>  is  included  to  allow 
for  the  possibility  that  t  contains  free  occurrences  of  variables  from  the  domain 
language  DL.  The  condition  val[s;  x  «■  e,  t,  VO  ^jLd  avoids  the  situation  in  which 
•  contains  some  identifiers  whose  value  is  undefined  in  «;  i.e.,  val{s,ei)  =_]_*;  for 
then  s,x+e  =_[_«•  Otherwise,  if  the  identifier  x  does  not  occur  in  t  and  t  is 
defined  in  t,  it  could  happen  that 

val(s,  e),  VO  =  val(t,  t,  f)  ^_L d, 

because  x  does  not  occur  in  t,  but 

val(s;  x  *-  e,  t,  f)  =  val(±„  t,  rp)  =±<. 
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Lemma  =*  Theorem:  To  see  that  the  lemma  implies  the  theorem,  assume  t,  x, 
e,  and  P  satisfy  the  restrictions  of  the  theorem,  and  that 

□(a,  P  «(x e)) 

is  true;  t.e.,  either 

val(t,  P«(x  4-  e),  { ))  =  true 

or 

val{s,  Po{m-e),  ())  =±d 

by  the  definition  of  the  □  operator  <6.19>  and  the  extension  of  vat  to  the 
assertion  language  <6.1  >. 

We  distinguish  between  two  cases: 

Cate:  val(t;  x  «■  e,  P,  ( ))  =  _|_«|.  Then  the  desired  conclusion 
D(s;  x  *  e,  P) 

is  true,  by  <6.1  >  and  <6.19>,  again. 

Cate:  val(t; x  «■  e,  P,  {))  ^J_d-  Then  by  the  lemma  (taking  t  to  be  P), 

val{s;x  +  e,  P,  ( ))  =  val[t,  P*«(x  *-  e),  ( )). 

But  we  know  that 

val(t,  P  o  (x  ♦-  e),  ( ))  =  true  or 
val(t,  P*»(x«-e),  ())=_]_ d, 

and  therefore 

val(t ;  x  «•  e,  P,  ( ))  =  true  or 
uoJ(a;x«-e,  P,  ())  =±*. 


In  either  case,  the  desired  conclusion 
□(«;x-e,  P) 
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is  true,  again  by  <6.1  >  and  <6.19>.  | 

It  remains  to  prove  the  lemma.  The  proof  depends  on  the  following  proposi¬ 
tion. 

Proposition  (static  assignment):  Suppose  s  is  a  state,  x  is  an  identifier,  and  e  is 
a  static  expression  in  PL,  such  that  loc{s,x)  is  a  storage  location,  i.e., 

isstore($,loc(s,x)). 

and  that  the  execution  of  the  assignment  x  *-  e  is  defined,  i.e., 
s;x«-e  t^JL,. 

Then 

•  The  location  bound  to  any  identifier  is  unchanged  by  a  static  assignment;  i.e., 
<7.7>  loc(s;  x  -  e,  y)  =  loc[s,  y)  for  all  identifiers  y 

•  Whether  a  location  is  a  storage  location  is  unaffected  by  a  static  assignment; 
i.e., 

<7.8>  isstore(s;x  «•  e,  a)  if  and  only  if  t**tore(s, a)  for  all  locations  a. 

•  The  location  yielded  by  evaluating  x  after  executing  the  static  assignment  x  *  • 
is  the  same  as  the  location  yielded  by  evaluating  e  before;  i.e., 

<7.9>  yield(s,  x  *■  e,  x)  =  yield(s,  •). 

•  Suppose,  in  addition,  that  x  is  not  pointed  to  by  an  expression  in  PL,  i.e., 

loc(s,x)  is  isolated, 

and  that  y  is  an  identifier  not  an  alias  of  x,  i.e., 
loc(s,  x)  loc(s,  y). 
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Then  the  location  yielded  by  the  evaluation  of  y  is  unaltered  by  the  assignment; 
*'e., 

<7.10>  yield{$,x  «■  e,  y)  =  yield($,  y). 

•  Futhermore,  the  value  of  x  after  executing  the  assignment  is  the  same  as  the 
value  of  e  before;  i.e., 

<7.1 1  >  val[s;  x  *■  e,  x)  =  val{»,  e) 

Proposition  =*  Lemma :  The  proof  of  the  lemma  is  by  induction  on  the  structure 
of  t.  In  other  words,  we  assume  inductively  that  the  lemma  holds  for  every 
proper  subexpression  tf  ot  t. 

Let  us  suppose  that  the  restrictions  of  the  lemma  are  satisfied  for  t;  thus 

(a)  x  is  not  an  alias  of  any  other  identifier  that  occurs  in  t ;  i.e., 

loc{s,  x)  loc(s,  w)  for  all  identifiers  w  in  t  such  that  w  ^  x. 

(b)  loc(s,x )  is  isolated;  i.e., 

loc[s,  x)  is  not  accessible  from  loc(s,  c'),  for  any  expression  of  in  PL. 

Therefore,  loc{&,  x)  satisfies  the  static  accessibility  property  <7.2 >: 
dato(s;x  *■  e,  a)  =  data(s,  a) 

for  every  location  a  such  that  a  ^  loc(s,  x). 

Let  us  suppose  also  that 

val(s;  x  *  e,  t,  rf>)  ^±d. 

It  follows  that  the  states  we  are  concerned  with  are  also  defined;  i.e., 
s  and  s;x**e^X« 

and  that  loc(s,  x)  is  a  storage  location;  i.e., 
s*«tore(*,foc(i,x)). 
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For  otherwise,  by  the  illegal  axiom  for  assignment  <5.9>, 
s;x*e  =J_,. 

We  attempt  to  derive  the  desired  conclusion,  that 
val(s;x  *■  e,  t,  ip)  =  val(«,  t  *>{x  ♦-  e),  ip). 

The  proof  distinguishes  between  several  cases,  depending  on  the  structure  of  t. 

Case:  t  is  an  expression  m  the  domain  language  DL.  Then  t  contains  no 
identifiers  of  the  programming  language  PL,  and  t^(x  *-  e)  is  t  itself.  Our 
desired  conclusion  reduces  to 

val{$;  x  -  e,  t,  ip)  —  val(s,  t,  ip). 

But  this  is  true,  because  the  value  of  any  expression  in  DL  is  independent  of  the 
state  <6.17>. 

Case:  t  is  the  identifier  x  itself.  Then  f  «(x  <—  e)  is  simply  e,  and  our  desired 
conclusion  is 

val{s,x  •*  e,  x,  VO  =  val(s,  e,  ip). 

Here,  x  and  e  are  static  expressions,  which  contain  no  domain  language  variables; 
therefore,  by  <6.18>,  their  values  are  independent  of  the  substantiation  ip,  and 
our  desired  conclusion  reduces  to 

val(s;  x  «-  e,  x)  =  val(s,  e) 

But  this  is  precisely  the  fifth  part  of  the  static  assignment  proposition  <7.11  >. 

Case:  t  is  an  identifier  y  distinct  from  x.  Then  t«(x  «-  •)  is  simply  y,  and 
our  desired  conclusion  is 

val[s,x  -  e,  y,  V)  =  val{s,  y,  ip). 

Because  y  is  a  static  expression,  its  value  is  independent  of  the  substantiation 
ip,  by  <6.2  > .  In  other  words,  our  conclusion  reduces  to 


val(s;  x  ••  e,  y)  =  vol(s,  y), 
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i.e.,  (by  the  definition  of  value  <3.10>), 

data(s; x  *•  e,  yield{s;x*t e,  y))  =  data(s,  yield(s,  y)). 

But 


data[s ;  x  «■  e,  yield(s ;  x  *  e,  y))  =  data(«;  x  •*  e,  yield{s,  y)) 

by  the  static  assignment 
proposition  <7.7> 

=  data(s,  yield[s,  y)) 

by  the  static  accessibility 
property  <7.2>. 

Note  that  in  this  last  step  we  have  relied  on  the  fact  that  loc(s,  x)  is  isolated,  and 
therefore  not  accessible  from  yield{s,y). 

Case:  t  is  of  form  •  •  •  ,tn),  where  f  is  a  pure  construct  in  the  program¬ 

ming  language  PL,  and  tj,  t2,  ...  tn  are  expressions  in  the  assertion  language  AL. 
Then  our  desired  conclusion  is 

val(s;x  +  e,  f(flft2,  4>) 

=  val{s,  «*(x«-e),  ip), 

i.e.  (by  properties  of  substitution), 

val{s;  x  «■  e,  f(t,,t2l  . . .  ,t»),  =  val[s,t[tt  o(x«-  e), 

i2*(x«-e), 


fn<»(x «-«)),  VO 

But,  by  the  extension  of  the  e/a/  operator  to  the  assertion  language  <6.9>,  this 
amounts  to  showing  that 


/d(uo/(s;  x  «■  e,  tj,  VO 
val(s;x  +  e,  t2,  ip) 


PROVING  HOARE’S  ASSIGNMENT  AXIOM  67 
t/af(*;x  *  e,  tn,  ip)) 

=  fd(val($,  *i  *{x  <-  e),  ^), 
val(»,  ta*{x*-  e),  ^), 

val(«,  tn-o(x«-e),  ^)). 

But  this  is  true,  because  Ilf *2,  ■  ■  ■  ,tn  are  all  subexpressions  of  t;  hence,  by  the 
induction  hypothesis,  we  have 

val(s;  x  *•  e,  t,-,  yr)  =  vaf(s,  t» «» (x  <-  e),  y»)  for  «  =  1, 2,  . . . ,  ». 

Note  that  we  are  justified  in  applying  the  induction  hypothesis  in  this  case: 
That  Conditions  (a)  and  (b)  are  satisfied  is  straightforward.  Furthermore,  we  have 
assumed  in  the  statement  of  the  lemma  that 

val(s;x  +  e,  t,  ip)^±d 

i.e., 

val(s,x  *  e,  f(ti,t2,  . . .  ,tn),  ip)  5*±4. 

By  the  extension  of  the  va/ operator  to  the  assertion  language  < 6.9 >,  this  means 
that 

fd{val(s;x  *■  e,  tu  ip), 
t>al(s;x«-e,  t2,  ip), 

val(8;x  +  e,  tn,  ip))  ^ ±d  • 

It  follows,  because  we  have  assumed  in  <4.2>  that  fd  is  a  strict  function  over 
the  domain,  that 

val(t;  x  e,  t„  ip)  ^±d 

for  each  t,t  =  1,2,  . . .  ,n.  But  this  is  precisely  the  condition  for  applying  the 
induction  hypothesis  of  the  lemma. 

The  cases  in  which  t  is  a  logical  expression  of  form  ,  tn),  tj  A  t3  A 

. . .  A  tn,  ti  V  ta  V  ...  V  tn,  -»£*,  etc.,  are  similar  to  the  above  case. 
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Case:  t  is  of  form  (Vw)t'.  Then,  because  t*  is  a  proper  subexpression  of  t,  our 
induction  hypothesis  tell  us  that 

if  val(s;  x  *  e,  if,  ip1)  ^±4 

then  x  «■  e,  t*,  ip1)  =  val(s,  t1  <>{x+-  •),  iff) 

for  any  s,  x,  e,  and  ip1  satisfying  the  conditions  of  the  lemma.  (Note  that  we 
have  renamed  the  dummy  variable  ip  to  be  tp1  to  avoid  confusion  with  the  ip  in 
the  conclusion  of  the  lemma). 

We  would  like  to  show  that 

tm/(«;x  «■  e,  (Vw)t',  ip)  =  val(s,  ((Vto)t')  <»(x «-  e),  ip), 

i.e.  (by  properties  of  substitution), 

val(s\  x  «-  e,  (Vu/)**,  ip)  =  val(s,  (Vw)(t/- s(x  «-  e)),  ^). 

We  consider  two  possible  subcases: 

Subcase:  val(s;x.  -  e,  (Vw)t',  V)  =  true.  Then,  by  the  extension  of  the  val 
operator  to  the  assertion  language  <6.12>, 

val(s ;  x  «■  e,  t\  (u; «-  d)  o  ^)  =  true 

for  every  data  object  d.  Therefore,  surely, 

val{s ;  x  *■  e,  if,  {w  *-  d)  o  ^) 

for  every  data  object  d.  Hence,  we  can  apply  our  induction  hypothesis  (taking  ip* 
to  be  (u>  <-  d)  o  ip)  to  deduce  that 

val(s,  tf  o(x  *-  e),  (w  <-  d)  o  ^)  =  true 

for  every  data  object  d.  It  follows  (by  the  extension  of  the  val  operator  to  the 
assertion  language  <6.12>  again)  that 

val(s,  {Vw){t!  <»(x  *-  e)),  ip)  =  true. 


Subcase:  val(s\ x  «*  a,  (Vw)?,  ip)  =  false.  Then,  by  the  extension  of  the  vof 
operator  to  the  assertion  language  <6.13>, 


val{s;  x  «•  e,  t1,  (to  4-  do)  0  ip)  =  false 
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for  some  data  object  do.  Therefore,  surely  for  that  data  object 
val(s;  x  *  e,  t*,  (to  «-  do)  ®  if) 

Hence,  we  can  apply  our  induction  hypothesis  (taking  if  to  be  (to  do)  o  to 
deduce  that 

val(s,  t*  «*(x  *-  •),  (to  *-  do)  o  if)  =  false 

It  follows,  (by  the  extension  of  the  va/ operator  to  the  assertion  language  <6.13>, 
again),  that 

val[s,  (VtoXf1 (x  < —  e)),  if)  =  false. 

In  both  subcases  we  have  shown  that 

vol(s;  x  «■  e,  (Vto)t',  it)  =  val(s,  (Vu>)(t'  o(x «-  •)),  i>); 
a  third  conceivable  subcase,  in  which 

t/af(s;x  «■  e,  (Vu/Jt1,  V»)  =±s, 

is  excluded  by  the  hypothesis  of  the  lemma. 

The  case  in  which  t  is  of  form  (3w)t'  is  similar  to  the  above  case  and  employs 
the  equivalence  between  (Bto)!*  and  -i(Vto)-itl.  The  case  in  which  t  is  a  set 
constructor  of  form  {to:  t'}  is  also  similar,  and  employs  the  extension  of  va l  to  set 
constructors  <6.16>,  t.e., 

val(s,  {to:  I1},  if)  =  the  set  of  all  data  objects  in  D  such  that 
val(s,  (to  ♦-  d)  o  i>)  =  true 

If  the  assertion  language  includes  other  constructs,  then  the  lemma  must 
also  be  pro1  .*  for  these  constructs,  using  the  corresponding  extension  of  the  val 
operator.  | 

This  concludes  the  proof  of  the  lemma.  We  still  must  prove  the  proposition. 
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Proof  of  Proposition: 

Suppose  that  s  is  a  state,  x  is  an  identifier,  and  •  is  a  static  expression  in 
PL  such  that 

isstore[s,  loc(s,  x))  and 

7*1*. 

It  follows,  by  the  illegal  axiom  for  assignment  <5.9>,  that 
isstore(s,  loc[t,  x)) 

and,  by  the  undefined  axiom  for  assignment  <5.10>,  that 

and  hence,  by  <3.13>,  that 
yield{»,  e)  ^±t. 

We  would  like  to  prove  the  following  five  properties: 

•  loc{s ;  x  *•  e,  y)  =  loc[s,  y)  for  all  identifiers  y. 

But, 

loe($;  x  *  e,  y)=  /oc(s;e,  y) 

by  the  frame  axiom  for  assignment  <5.2> 

=  /oc(s,y) 

by  the  static  expression  lemma  <4.3>  and 
the  properties  of  indistinguishability  <3.1 5  > 

•  isstore(s;  x  «■  e,  t)  if  and  only  if  isstore(s,  l)  for  all  locations  l. 

The  proof  is  similar,  by  the’ frame  axiom  for  assignment  <5.6>,  the  static- 
expression  lemma  <4.3>,  and  the  definition  of  indistinguishability  <3.20>. 

•  yield(»\  x  «■  e,  x)  =  yield[s,  e). 

Note  that,  because  we  have  supposed  that 

i»store{8,  loc(t,  x)), 
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it  follows,  by  the  first  two  parts  of  this  proposition,  <7.7>  and  <7.8>t  that 
isstore(s;  x  «•  e,  loc(s;  x  *  e,  x)). 

But  then 

yield(8\  x  *-  e,  x)=  store[a;  x  e,  loe(t;  x  «*  e,  x)) 

by  the  definition  of  the 

yield  operator  for  identifiers  <3.9>, 

=  8tore(»]  x  «•  e,  loe(»,  x)) 

by  the  first  part  of  this  proposition  <7.7> 

=  yield(»,  e) 

by  the  principal  assignment  axiom  <5.1  >. 

•  Suppose  that,  in  addition,  loc(s,  x)  is  isolated,  and  that  y  is  an  identifier  such 
that 

/oc(s,  x)  7^  /oc(s,  y). 

We  would  like  to  show  that 

yitld{*\  x  «■  e,  y)  =  yield{»,  y). 

The  proof  distinguishes  between  two  cases,  depending  on  whether  or  not  y 
is  bound  to  a  storage  location.  (If  y  is  bound  to  the  undefined  location,  the 
conclusion  follows  from  the  strictness  of  the  situational  operators.) 


Cate.  i$store[t,  loc(s,  y)).  It  follows  that 
isstore(s ;  x*-e,  loc(s;  x  *■  e,  y)), 

by  the  first  two  parts,  <7.7>  and  <7.8>,  of  this  proposition.  By  the  definition 
of  the  yield  operator  <3.9>,  in  this  case,  our  desired  conclusion  reduces  to 

store(s ;  x  «■  e,  loc(s;  x  +  e,  y))  =  store(s,  loc(t,  y)). 


But, 

ttore[f,  x  +  e,  ioc(t;  x  «•  e,  y) 

=  ttore[f,x  *  e,  loe{t,  y)) 

by  the  first  part  <7.7>  of  this  proposition 
=  store[s ;  e,  loc(s,  y)) 

by  the  frame  axiom  for  assignment  <5.3> 
=  »tore(t,  loc[8,  y) 

by  the  static  expression  lemma  <4.3> 
and  the  definition  of  indistinguishability 
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Cate.  not  i$store(t,  loe{$,  y)).  It  follows  that 
not  i sstore(s;x  *■  e,  loc(t;x  •*  e,  y)) 

by  the  first  two  parts  of  this  proposition,  <7.7>  and  <7.8>.  It  also  follows,  by 
<3.3>,  that  y  is  bound  to  a  data  location  or  a  structure  location  in  both  state 
s  and  state  s;x  «■  e.  By  the  definition  of  the  yield  operator  in  this  case  <3.8>, 
our  desired  conclusion  reduces  to  simply 

loc(s,x  +  e,  y)  =  loc(s,  y), 
which  is  the  first  part  <7.7 >  of  this  proposition. 

•  Suppose  again  that  loc{$,  x)  is  isolated.  We  want  to  show  that 
val{r,  x  «•  e,  x)  =  val(s,  e). 

By  the  corollary  <4.3>  to  the  static  expression  lemma,  our  desired  conclusion 
in  this  case  reduces  to 

data(s ;  x  «•  e,  yield{s ;  x  *■  e,  x)  =  data(t,  yield(»,  •)), 
because  x  and  e  are  both  static  expressions.  But 

data(s;  x  **  e,  yield(s ;  x  *  e,  x)) 

=  data[8,x  *■  e,  yield{8,  e)) 

by  part  <7.9>  of  this  proposition 
=  data{s,  yield[s,  e)) 

by  the  static-accessibility 
property  <7.2>, 
because  loc[8,  x)  is  isolated 

This  concludes  the  proof  of  the  proposition. 

We  have  shown  in  this  section  that,  if  an  appropriate  set  of  restrictions  is 
satisfied,  the  Hoare  assignment  axiom  is  true  and  can  be  proved  as  a  theorem. 
In  some  simple  programming  languages  these  restrictions  will  always  be  satisfied 
and  we  can  apply  the  assignment  theorem  with  no  second  thoughts.  In  the 
more  complex  programming  languages  we  find  in  practice,  we  can  still  apply  the 
theorem  if  we  can  manage  to  prove  that  the  restrictions  are  satisfied. 

In  languages  for  which  the  Hoare  axiom  does  hold,  the  complexity  of  deduc¬ 
tions  will  be  greatly  reduced  by  application  of  the  above  theorem.  In  general,  for 
languages  with  similarly  regular  properties,  we  can  shorten  proofs  by  establishing 
these  properties  as  theorems.  The  full  power  of  the  situational  calculus  is  required 
only  for  languages  without  such  regular  properties. 

In  the  next  section,  we  will  deal  with  a  more  powerful  class  of  expressions 
for  which  the  assignment  theorem  does  not  hold. 
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Now  let  us  consider  the  class  of  “assignment  expressions*  obtained  by  freely 
intermixing  the  assignment  operation  and  the  pure  constructs.  This  class  is  a 
subclass  of  the  expressions  allowed  in  several  programming  languages,  such  as  the 
ALGOL  dialects  and  LISP. 

More  precisely,  we  define  the  assignment  expressions  by  the  following  rules: 

•  Any  identifier  x  in  PL  is  an  assignment  expression. 

•  If  f  is  a  pure  construct  and  •»,  e*,  are  assignment  expressions,  then 

f(ei,  02 1  ....  en)  is  an  assignment  expression. 

•  If  x  is  an  identifier  and  e  is  an  assignment  expression,  then  x  «■  •  is  an  assignment 
expression. 

•  If  «i,  «2,  . . . ,  en  are  assignment  expressions,  then  eu  eat  . . .  t  •»  is  an  assign¬ 
ment  expression. 

For  example, 

x  *  ((y  *  2)»(x  «■  (x+1)))  +  (y  *  (a-1))  ♦  * 
is  an  assignment  expression. 

Thus,  in  an  assignment  expression  one  assignment  statement  may  occur  on 
the  right-hand  side  of  another.  For  this  reason,  the  Hoare  axiom  fails  to  hold  for 
general  assignment  expressions.  However,  we  can  prove  the  following  proposition, 
which  allows  us  to  shorten  many  deductions  concerning  assignment  expressions. 

First,  let  us  define  a  left  identifier  of  an  expression  a  to  be  one  that  occurs 
on  the  left-hand  side  of  an  assignment  in  e  ,  and  a  right  identifier  to  be  one  that 
occurs  anywhere  else.  Thus,  in  the  above  example,  x  and  y  are  left  identifiers, 
and  x  and  z  are  right  identifiers.  Note  that  the  same  identifier  can  be  both  a  left 
and  a  right  identifier. 

Proposition  (assignment  expression):  Suppose  $  is  a  state,  x  an  identifier,  and  • 
and  e'  are  assignment  expressions  in  PL,  such  that  x  is  not  pointed  to  by 
any  expression  in  PL,  i.e., 

loc(s,  x)  is  isolated, 
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and  the  evaluation  of  the  assignment  x  «■  •  is  defined,  i.e., 

Then  we  have 

•  principal  assignment 

<8.1  >  val{s\ x  «■  e,  y)  =  val(s,  e) 

if  y  is  an  alias  of  x  ,  i.e.,  if  loc(s,x )  =  loe(s,y); 

•  value  of  assignment 

<8.2>  i ial(s,  x  «■  e)  =  val(s,  e); 

•  frame  assignment 

<8.3>  va/(e; x  «■  e,  e1)  =  va/(s; e,  •') 

if,  for  every  right  identifier  z  of  e',  loc(s,  x)  7^  /oc(s,  z) 

•  frame  expression 

<8.4>  val(s;e,  e')  —  val(s,  e1) 

if,  for  every  left  identifier  y  in  e  and  every  right  identifier  z  in  e',  loc(e,  y)  7^ 
loc(s,z)  and  loc{s,y)  is  isolated. 

We  are  not  going  to  prove  this  proposition;  the  argument  is  reminiscent  of 
the  previous  section.  However,  we  will  present  some  counterexamples  to  indicate 
why  the  restrictions  on  this  proposition  are  required. 

Let  us  suppose  that  the  following  configuration  exists  in  state  1: 


Figure  8.1 
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Here  loc(s,  x)  is  not  an  isolated  location,  and  the  value  of  z  is  0,  i.e.t 
val{»,z)  =  0. 

If  we  execute  the  assignment  x  «*  z  in  this  state,  we  create  the  configuration 
illustrated  below: 


Figure  8.2 


Here  the  identifier  x  is  bound  to  a  looping  data  structure.  We  have  not  jet  defined 
the  data  object  represented  by  a  looping  data  structure,  but  it  is  fair  to  assume 
that 


t ;al(s;x  «■  z,  x)  ^  0. 

In  other  words,  we  have  obtained  a  contradiction  to  the  conclusion  of  the  principal 
assignment  proposition  val(*;x  «•  e,  y)  =  val(s,  e)  <8.1  >  by  taking  •  to  be  z 
and  y  to  be  x  .  Similar  contradictions  are  obtained  from  this  example  for  the 
conclusions  to  the  other  parts  of  the  assignment  expression  proposition.  In  fact, 
any  configuration  in  which  an  identifier  is  assigned  a  structure  that  points,  however 
indirectly,  to  that  identifier  will  lead  to  counterexamples  to  the  proposition. 

Another  counterexample:  the  conclusion  of  the  frame  expression  proposition, 
t /al(e;e,  o')  =  val{»,tf),  <8.4>,  is  contradicted  immediately  if  we  take  •  to  be 
x  x  ♦  1  and  e'  to  be  x;  t.e., 

vaf(«;x  *  x  ♦  1,  x)  ^  val[»,  x). 

Here  a  condition  for  the  proposition  was  violated  because  a  left  identifier  x  of  • 
is  an  alias  of  a  right  identifier  x  of  e1  (in  fact,  they  are  identical). 


76  ASSIGNMENT  EXPRESSIONS 
Example : 

Let  us  use  the  assignment  expression  proposition  to  characterise  the  effect  of 
the  assignment  expression 

*  *  ((y  *  (y+2))  ♦  x), 

in  a  state  s  in  which  the  identifiers  x  and  y  are  bound  to  isolated  storage 
locations  that  represent  numerical  values.  We  suppose  that  val(»,  2)  =  2  and 
that  the  programming  language  construct  ♦  is  a  pure  construct  associated  with  the 
ordinary  function  -f*  over  the  numbers.  (Thus  we  ignore  the  vagaries  of  computer 
arithmetic.) 

(a)  val{$;  x  «■  ((y «-  (y  +  2))  +  x),  x)  =  uo/(s,  x)  +  val{$,  y)  +  2 

if  /oc(s,x)  loc{s,  y) 

(b)  val(s;  x  «■  ((y  «■  (y  ♦  2  ))  ♦  x),  y)  =  val(t,  y)  +  2 

if  loc(s,  x)  loe(s,  y) 

(c)  val(s;  x  «■  ((y  «•  (y  +  2  ))  +  x),  x) 

=  val{s;  x  *■  ((y  (y  +  2))  +  x),  y)  =  2  •  val{ $, y)  +  4 
if  4oc(*,x)  =  loc[s,  y). 


We  will  prove  both  (a)  and  (c);  the  proof  of  (b)  is  similar. 

Proof  of  (a)\  We  assume  loc(s,x)  7^  loc(s,  y).  Then 

val(s;  x  *■  ((y  «■  (y  ♦  2»  +  x),  x) 

=  val{»,  ((y  «■  (y  ♦  2))  ♦  x)) 

by  the  principal  assignment  proposition  <8.1  > 

=  val{s,  y  «■  (y  ♦  2))  +  wo /(*;  y  «■  (y  ♦  2),  x) 
by  the  pure- value  axiom  <4.2> 

=  val(s,  y  ♦  2)  +  val(s;  y  +  (y  ♦  2),  x) 

by  the  value  of  assignment  proposition  <8.2> 

=  v al(s,  y)  -f  val(s,  2)  +  val(s;  y  +  (y  +  2),  x) 

by  the  corollary  to  the  static-expression  lemma  <4.5> 

=  val(s,  y)  +  2  +  v o/(s;  y  *  (y  «•  2),  x) 
by  our  supposition 
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=  val(8,  y)  +  2  val(t,  x) 

by  the  frame  expression  proposition  <8.4  > 
because  loe(»,  y)  ^  loe(s,  x)  and  loc(s,  y)  is  isolated. 


Proof  of  (c)\  We  assume  ioc(s,  x)  =  loc(s,  y).  Then 

oa/(s;  x  «■  ((y  «■  (y  ♦  2»  ♦  x),  x) 

=  val{8,  y)  +  2  +  va/(s;y  +  (y  +  2),  x) 
as  in  the  proof  of  (a) 

=  val(s,  y)  +  2  +  val(s,  y  ♦  2) 

by  the  principal  assignment  proposition  <8.1  >, 
since  loc(s,  x)  =  loc(s,  y) 

=  val(s ,  y)  +  2  +  val(s,  y)  +  2 
as  in  the  proof  of  (a) 

=  2  •  val[s,  y)  -f  4 

These  computations  are  tedious,  but  purely  mechanical.  | 


DISCUSSION 


This  concludes  our  treatment  of  the  simple  assignment  statement;  in  Parts 
II  and  III  of  this  paper  we  will  apply  the  same  approach  to  data  structures  and 
procedure  calls.  We  will  defer  a  full  discussion  of  this  approach  and  a  comparison 
with  other  approaches  until  the  end  of  Part  III.  At  this  point,  however,  we  can  say 
a  few  words  comparing  the  situational  calculus  to  both  early  and  contemporary 
work  in  the  description  of  programming  languages. 

The  situational  calculus  was  employed  by  McCarthy  [1962]  and  Burstall 
[1969]  to  describe  subsets  of  ALGOL-60.  However,  the  approach  has  not  been 
further  developed  or  pursued  in  program  verification  systems,  perhaps  because  of 
the  apparent  relative  simplicity  of  the  Floyd/Hoare  approach. 

The  denotational  approach  of  Scott  and  Strachey  (see,  e.g.,  Gordon  [1979]) 
resembles  the  situational-calculus  approach  in  scope.  In  the  denotational  ap¬ 
proach,  the  meaning  of  a  program  is  represented  by  a  formula  of  the  lambda 
calculus,  whose  treatment  involves  the  manipulation  of  lambda  expressions.  The 
situational  calculus  avoids  such  expressions,  and  can  therefore  exploit  such  first- 
order  theorem-proving  techniques  as  unification.  For  this  reason,  we  find  the 
situational  calculus  more  amenable  to  implementation  in  automatic  verification 
and  synthesis  systems. 
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